mem0/integrations/deepseek-plugin/README.md

deepseek-plugin

Mem0 long-term memory as a native DeepSeek Harness (Cordis) plugin.

It gives a Harness agent automatic long-term memory plus two explicit memory tools backed by the Mem0 SDK:

Capability	Does
Auto-recall	Searches Mem0 for the latest human prompt and adds unseen results to the model context
Auto-capture	Stores the human/assistant messages from each completed turn
search_memory	Recall facts from Mem0 relevant to a query
add_memory	Store a fact in Mem0 for future sessions

Unlike the local/file-based memory plugins in the ecosystem, Mem0 is a managed backend: server-side extraction, semantic dedup and conflict resolution, and memories that other agents can retrieve when their user and entity filters match.

Current package version: 0.3.1.

Sidekick is available only in the Claude Code plugin.

How it works

A Cordis plugin is a module exporting apply(ctx, config). This one waits for the Harness tool and system-prompt services, then uses the native extension points:

• system-prompt/assemble recalls memory before a model request.
• session/event captures only completed turns from the durable event stream.
• ctx.tools.register(...) exposes explicit search and add tools.

Completed human and assistant text is preserved after secret redaction, without the former 6,000-character per-message cutoff. Recall queries and displayed tool results retain separate size limits. These behaviors use agent-plugin-core; this integration keeps its native tools and user-based scoping.

Cordis owns listener and tool cleanup when the plugin unmounts. Every automatic path is fail-open: a memory API failure does not block the agent.

[ mem0ai SDK ]  <-- managed memory, owned by Mem0
      |
[ deepseek-plugin: prompt + session listeners, memory tools ]  <-- this package
      |
[ DeepSeek Harness ]  <-- the agent, loaded via cordis.yml

Try it locally

1. Build and pack the plugin:

   cd integrations/deepseek-plugin
   pnpm install --frozen-lockfile
   pnpm build
   mkdir -p /tmp/mem0-deepseek-plugin
   pnpm pack --pack-destination /tmp/mem0-deepseek-plugin
   

2. Set your Mem0 key, a stable user identity, and a funded model API key:

   export MEM0_API_KEY=...
   export MEM0_USER_ID=your-user-id
   export DEEPSEEK_API_KEY=...
   

3. Install it into a disposable Harness profile:

   DSH_HOME=/tmp/mem0-dsh-dev pnpm dlx @deepseek-ai/dsh@0.1.1-rc.2 \
     plugin --profile web add /tmp/mem0-deepseek-plugin/mem0-deepseek-plugin-0.3.1.tgz
   

4. Run Harness with the same profile. The installed bundle activates Mem0 automatically:

   DSH_HOME=/tmp/mem0-dsh-dev pnpm dlx @deepseek-ai/dsh@0.1.1-rc.2 \
     web
   

5. Open http://127.0.0.1:3080, select a workspace, and state a synthetic preference without mentioning Mem0. Wait for asynchronous extraction to finish, then start a fresh session and ask for that preference without tools. Inspect the mem0:recall context to verify automatic recall.

Build from the full repository: the source imports the sibling shared core. pnpm pack runs the build and includes the activation patch. An installed tarball is self-contained. For custom settings, copy cordis.example.yml and pass its absolute path with --patch. When upgrading from the old manual setup, remove the old patch that inserts a mem0 row; the bundle now inserts it.

On macOS, set CHOKIDAR_USEPOLLING=1 if Harness reports EMFILE. The Mem0 key and model-provider key are separate credentials.

For a Mem0 Platform on-prem or dedicated deployment, point config.host at that base URL (defaults to api.mem0.ai). host overrides the Platform base URL. It does not support the self-hosted Mem0 OSS API.

Configuration

Field	Required	Default	Notes
apiKey	no	$MEM0_API_KEY	Mem0 platform API key
userId	yes		Entity that owns the memories
memoryScope	no	user	user shares memory across workspaces; workspace isolates all automatic and explicit operations by the session workspace
allowUserOverride	no	false	Permit model-selected access to a different user only in a trusted multi-user deployment
host	no	api.mem0.ai	Platform base URL (on-prem / dedicated)
autoRecall	no	true	Recall relevant memory before model requests
autoCapture	no	true	Store completed human/assistant turns

Memory scope

Automatic capture and recall use the configured userId across sessions. Automatic writes do not attach a repository ID or runId.

This cross-workspace sharing is intentional compatibility behavior. Set memoryScope: workspace in the profile patch to isolate memory. The plugin then adds an appId derived from the canonical absolute session workspace path to every write and the matching app_id to every search. Symlink aliases share a scope; different directories (including separate clones or worktrees) do not. Moving a workspace changes its scope. Tools cannot override it. Missing or invalid workspace paths skip automatic memory operations and reject explicit tools, without falling back to user-wide access.

Workspace scope does not migrate existing user-only memories. User scope still searches all memories for that user, including workspace-tagged memories; isolation applies when the plugin is configured with workspace scope. These filters are application-level separation, not separate Mem0 credentials.

Both search_memory and add_memory accept optional agentId and runId. On search, these narrow the returned memories; on add, they attach those identities to the stored memory. Pass a known runId to search memories explicitly saved with that session ID. This does not include automatically captured user-only memories or identify the session making the request.

Per-call userId overrides are rejected unless the operator enables allowUserOverride: true. Automatic recall and capture always use the configured user.

Extraction and recall limits

The plugin sends full redacted completed turns to Mem0; Mem0 extracts the memories asynchronously. A queued write is not proof that every extracted fact is already searchable. Even an initial nonempty memory list can be incomplete. Check the stored memories after processing before diagnosing extraction loss.

Automatic recall is a bounded first pass (up to five results, 4,000 context characters, and a two-second wait). search_memory uses a focused query and returns up to ten results by default. Exact preference extraction remains model-dependent; include filenames and numeric constraints in release tests, and distinguish standing preferences from one-off requests.

Telemetry

Writes are tagged source="DEEPSEEK_HARNESS" so Mem0's backend can attribute usage to this integration. For it to surface by name (rather than bucketing into OTHERS), DEEPSEEK_HARNESS must be present in the backend's KNOWN_EVENT_SOURCES allowlist, a one-line platform change matching the existing ZAPIER / STRANDS sources.

The plugin also sends anonymous usage events (which tool ran, duration, result counts, coarse failure kind) so Mem0 can tell how the plugin is used and where it breaks. Queries, memory text, and entity ids are never sent. Turn it off with MEM0_TELEMETRY=false.

Status

Developer preview. Tracks the DeepSeek Harness v0.1 plugin API, which is young and moving. Harness capability packages are peer dependencies supplied by the host; this package pins matching release-candidate versions for local typechecking and tests.