Paperclip merges opt-in memory providers with a server-side remote relay

Paperclip's newly merged memory integration combines Mem0, Zep, Supermemory, Cognee and Honcho with remote access through its managed tool gateway. Rather than putting each provider's credentials into a sandbox, the native Codex runner relays assigned calls back to the server. This is an optional set of tool connections, not automatic synchronization of every conversation. The practical question is who may invoke which memory operations—and whether successful storage has actually become retrievable knowledge.

The facts

- PR #13942 merged September 24 with an experimental memory-connector catalog that defaults to off. - The implementation offers OAuth for Zep and Supermemory and API credentials for Mem0 and Honcho. - Cognee uses a bundled Cloud API bridge; its final path does not start a credential-bearing local subprocess. - The connector document says active actions default to Allowed, including writes and deletion, unless operators narrow them. - Turning off the experimental catalog blocks new curated setup but leaves existing connections usable. - The final acceptance additions report Supermemory write/semantic recall and a fresh Cognee bridge store/recall run through Daytona.

Why it matters

Memory is often described as a passive feature, but these integrations are active data tools. The documentation explicitly rules out an automatic conversation upload or background sync; an agent must call them. That creates a useful review point, provided the action policy matches the operator's intent. It also makes provider-side permissions important: a workspace or user selector passed as a tool argument is not itself a tenant-isolation guarantee. The provider's account scope and Paperclip's agent grants need to agree about whose information may be read or changed.

Current

This is merged development source, with v2026.916.1 still the inspected stable tag. The detailed evidence evolved during September 24: early Supermemory tests had read-only consent, while later entries report scoped writes and semantic recall after indexing. The final Cognee path was retested after switching to a bundled bridge. Earlier limitations should remain attached to those earlier runs, not overwrite the later result or be silently omitted from its history.

Evidence

Primary: paperclipai/paperclip PR #13942 (https://github.com/paperclipai/paperclip/pull/13942). Supporting context: paperclipai — MEMORY.md (https://raw.githubusercontent.com/paperclipai/paperclip/591043d530e4c2b95f15cb810a11d5ed75ec26a0/doc/connections/MEMORY.md); paperclipai/paperclip PR #13942 — implementation diff (https://github.com/paperclipai/paperclip/pull/13942/files). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.

Operator take

Before enabling the experiment, decide separately whether an agent may retrieve, store or delete memories. Consider Ask first for writes and destructive actions rather than mistaking off-by-default discovery for restrictive runtime permissions. For a pilot, use synthetic information with a distinctive expected answer, then check storage, indexing and recall as separate steps. The reported delayed-indexing behavior is precisely why an accepted write is not enough. For remote runs, verify that audit records attribute the call to the right task and that provider secrets remain outside the sandbox.

Caveat

Live acceptance is reported by the project and covers specific synthetic journeys, not every provider tool or plan. Source inspection is not an independent account test. An Allowed action can still fail under provider scopes or indexing delays; the experiment switch is not an emergency revocation control.