One memory across Claude Code and Codex CLI
Most people run more than one coding agent. If each one keeps its own memory, you teach the same lesson twice. Point both at one Remnic store and what one agent learns, the other can recall.
Short answer: run one Remnic daemon and install the Claude Code and Codex CLI connectors against it. Both agents then read and write the same memory store, so a preference you tell one can be recalled by the other. Memory stays scoped to the project you are working in.
The problem with one memory per tool
Claude Code and Codex CLI are good at different things, and plenty of developers keep both in reach. The trouble is memory. If each agent has its own private notes, you correct a convention in Claude Code on Monday and Codex repeats the old mistake on Tuesday. Two agents, two blank slates, twice the re-explaining.
The fix is not a smarter model. It is a shared store both agents talk to. Remnic runs as one local daemon that holds your memory, and each agent connects to it as a client. Recall and storage go through the same store no matter which agent is asking.
Install both connectors
Remnic ships connectors that wire a coding tool into your memory store. Install the ones you use:
remnic connectors install claude-code
remnic connectors install codex-cliThe Codex CLI connector publishes its memory extension directly. The Claude Code connector mints the token and writes the config, and its host wiring is completed by hand, so follow the exact steps on the Claude Code integration page after installing. You can check either one with remnic connectors doctor <id>, which reports the connector’s own checks and its publisher status.
Both connectors point at the same running Remnic daemon. That single detail is what makes the memory shared: there is one store on disk, and each agent is just another client reading and writing it.
One store, two agents
With both connected, the flow you want works. Tell Claude Code a durable preference, for example that you prefer a particular test runner or that a service should never be called directly. Remnic stores it. Later, in Codex CLI, that preference is available through recall, because Codex reads the same store Claude Code wrote to.
The reverse holds too. A decision Codex records is there for Claude Code. You teach a lesson once and both agents can act on it, instead of maintaining two parallel sets of notes that drift apart.
Recall is still a retrieval step, not a guarantee that every past note appears on every prompt. Remnic recalls what is relevant to the current task, which is what keeps the context focused rather than dumping the whole store into every request.
Project-scoped by default
Sharing memory across agents raises an obvious worry: does what you learn in one project leak into another. It does not. When a session runs inside a git repository, Remnic scopes memory to that project automatically. It derives a stable project id from the repo, so two clones of the same repository resolve to the same scope, and different repos stay separate. Writes land in the project scope, and reads use that scope first.
What an agent learns while working on project A does not surface while you work on project B. There are no environment variables to set and no namespace flags to pass; if the working directory is inside a repo, project scoping activates on its own.
Genuinely global facts are the deliberate exception. A personal preference, a framework quirk, or a library behavior that is true everywhere is promoted to a shared scope so it reaches every project and every connected agent. Project-specific notes stay put. The result is one preference that follows you across both agents and across repos, without cross-contaminating project detail.
More than two agents on one store
The same daemon is not limited to two clients. Remnic connects to a range of coding tools, and every one of them reads and writes the store you already have. Add Cursor, Pi, or an OpenClaw session and they join the same memory rather than starting a fresh silo. The mechanics are identical: install the connector, point it at the running daemon, and the store is shared. This is the payoff of a local memory layer over a per-tool feature. You maintain one store, back up one directory, and every agent you run benefits from the same accumulated context.
What to store, and what to skip
Shared memory is only as useful as what goes into it. The memories that earn their place are the durable ones: decisions and their reasoning, conventions you have corrected, setup quirks specific to your machine, commands that worked, and approaches that failed so no agent retries them. These are the facts you would otherwise re-type into every new chat.
Skip the transient. The exact contents of one file, a one-off command, or the state of an in-progress edit do not belong in long-term memory; they belong in the current session. Remnic extracts durable facts on its own and holds lower-confidence candidates for review, so you are not forced to curate every line by hand, but a quick habit of storing real decisions and ignoring noise keeps recall sharp for both agents.
See it work
There is a walkthrough that demonstrates the cross-agent, project-scoped path end to end, from teaching a fact in one agent to recalling it in another. Read the coding agent memory demo to see the exact prompts and what recall returns.
Set it up
Install the Remnic CLI from the install guide. Then wire up each agent using its integration page: Claude Code and Codex CLI. With both connectors pointed at the same daemon, set a preference in one agent and ask the other to recall it to confirm the store is shared.