Memory for coding assistants
Two commands wire a coding tool to SodaMem:
sodamem daemon ensure # the one process that owns the stores
sodamem install claude-code # wire a client to itEvery supported client gets the MCP tool surface. Four also get hooks, so memory is recalled and retained without the model having to decide to call a tool — which in a coding session it mostly doesn't, because it is busy reading files.
What each client actually supports
Hook systems are not uniform, so neither is this table. sodamem clients prints the same thing.
| Client | Recall | Retain |
|---|---|---|
| Claude Code | every prompt | every turn + session end |
| GitHub Copilot CLI | every prompt | every turn |
| Cursor | session start (project brief) | — |
| Codex CLI | session start (project brief) | — |
| Claude Desktop, VS Code, Windsurf, Zed, OpenCode | MCP tools only | MCP tools only |
Cursor's beforeSubmitPrompt can read a prompt but cannot inject anything — its documentation lists exactly three events that can, and that is not one of them. Neither Cursor nor Codex hands a hook a transcript path, so a retain hook would have nothing to read. Those two get a project brief at session start and write through the add_memories tool instead. We do not install a hook that can only ever do nothing.
Three things to know first
One daemon, many editors
Per-user stores are SQLite without WAL, so exactly one process may open them (ADR 0001 §2). install therefore points every client at a running service by default rather than letting each spawn its own.
If you deliberately choose a local store with --local-store, a second client now refuses to start instead of quietly corrupting the first one's data.
Memories are scoped to the repo
install derives a project_id from the git root. A git worktree resolves to its parent repo, so one branch per task is not one memory bank per task.
This is narrowing, not partitioning: anything you told SodaMem outside a project still surfaces inside every project, and dropping the key answers "how did I fix this in the other repo?". See Scoping.
Retain needs extraction credentials
Recall is zero-LLM and works without them. Storing facts does not. sodamem daemon ensure says so up front rather than accepting every write and failing the job afterwards. Set the variables from Environment variables.
Useful invocations
sodamem install claude-code --dry-run # print what would change
sodamem install cursor vscode zed # several at once
sodamem daemon status # what is actually answering
sodamem clients # what install supportsExisting configuration is merged, not replaced — other MCP servers, other settings and hand-written TOML comments survive — and the first write of any file leaves a .sodamem-backup beside it.
Full flag list: CLI reference.
Writes are off unless you ask
Six of the eight MCP tools are reads and are always available. The two that mutate (add_memories, delete_memory) appear only under SODAMEM_MCP_ALLOW_WRITE=true, which sodamem install writes for you into the client config it generates.