Use Multiple Coding Agents on One Shared Memory

You already alternate between Claude Code, Codex, and OpenCode — but each one starts blank. Here is how to run multiple coding agents on one shared project memory: one key, three plugins, a cross-tool recall check, and habits that keep it clean.

Separate chat histories, one project: the parity problem

You rotate tools out of habit: Claude Code for the long refactor, Codex for fast terminal edits, OpenCode for a second checkout or a different machine. Each of them keeps its own chat history, and none of those histories is visible to the others. A convention you taught one agent on Monday is unknown to the second agent on Tuesday, even though both work the same repo.

The failure mode is boring and expensive. The new tool asks which package manager the repo uses, proposes a directory layout you already rejected with a reason, and reruns a migration in the order that already broke staging. Every repeated question costs turns, and every repeated mistake costs a review cycle. The repository never changed; only the conversation did.

Single-tool memory habits do not cross this boundary. Compaction rewrites one conversation lossily, /clear discards it, and a fresh terminal never had it — but even a perfect transcript inside Claude Code stays invisible to Codex. Pasted summaries decay faster than transcripts: they drop the one-line reasons behind decisions, go stale the moment the task turns, and give the receiving agent no way to query what the note left out.

You need one project record outside every chat: conventions, decisions with reasons, and gotchas, stored once and read by every tool. That shared record resolves the parity problem that appears as soon as multiple coding agents share one repo — separate histories, one project.

One project key shared by multiple coding agents

Create one project per repo and point every agent at its ak_ project key. One project per repo keeps recall precise: when an agent opens the checkout service, it gets checkout facts back, not rules from an unrelated side project. Projects are unlimited on every plan from Hobby through Enterprise, so per-repo scoping costs nothing extra.

Treat that key like a secret. Use the same project key in all three plugin configurations on your machine, and never commit it to the repo. If a second developer joins the repo, they connect to the same project, so their agents read the same memory your agents write. The quickstart shows the REST equivalent of these operations, against the data plane at https://api.memory.audaxic.com with a pinned date-based X-Api-Version header, currently 2026-09-25.

Confirm the key match before you rely on shared recall. Two tools with different project keys hold two separate memories with no shared context. The failure looks exactly like empty memory: both agents work in isolation while sharing nothing. Store one test fact in the first agent and retrieve it from the second; if retrieval fails, the keys differ, and you fix a config line instead of debugging a workflow.

Install each plugin on the same key

Install all three plugins with the project key from the previous section:

npx @audaxic/memory-claude install
npx @audaxic/memory-codex install
npm install -g @audaxic/memory-opencode

Each plugin does the same two jobs: it saves facts as you work and injects relevant memories when a session starts. State a decision in plain language in Claude Code and the plugin extracts it as a fact. Open Codex later and its plugin injects that fact at session start. The three plugin docs linked above show where the key lives for each plugin.

What this is not: no orchestration layer, no parallel-run feature, no per-tool sync to configure. This is one shared project memory used by tools you already run: you alternate between them as before, and each session starts informed by what the others stored. If several developers share the repo, each installs the plugins for the tools they personally use — nobody needs all three.

Bringing another tool with existing history onto the same key? Run npm install -g @audaxic/memory-import first, then follow the guide to importing past Claude Code, Codex, and OpenCode conversations into shared memory so the project starts with that history at the correct timestamps.

Verify cross-agent recall before trusting it

Cross-tool recall is the proof that multiple coding agents actually share one memory, so verify it before doing real work. The check takes a few minutes and catches the two common failures: mismatched keys and facts that were never stored.

First, write in one tool. In Claude Code, state three things in plain language: the package manager and test command for the repo, one layout or design decision with its reason, and one gotcha the repo taught you — a staging quirk, a flaky test, a migration ordering rule. Give the plugin a turn to save. The plugin cannot store a fact you never state.

Second, read in another tool. Open Codex in the same repo and ask recall-first questions before assigning work: which package manager and test command this repo uses, what the layout decision was and why, and which staging gotcha the next change must respect. A working setup answers all three without repetition. Then reverse the direction: store a new fact in Codex — a branch rule, a fresh constraint — and retrieve it from OpenCode.

If recall fails, diagnose in order. Confirm the project key matches in both configurations first — a mismatched key is the most common cause. Then confirm the fact exists: call GET /list with a small limit and scan for it, or run POST /search with the task terms. GET /list is paginated with limit and offset, so pull the first page before assuming anything is missing. If the fact is absent, restate it to the first agent in plain language and let the plugin extract it.

This steady-state alternation differs from a single mid-task transfer. If your goal is starting a task in one tool and finishing it in another in one pass, the Claude Code to Codex handoff walkthrough covers that workflow step by step. This guide covers the other pattern: alternating tools side by side over weeks.

MCP clients join the same project memory

The same project memory serves agents inside MCP-compatible clients: Cursor, Windsurf, Claude Desktop, and any other MCP-compatible client. These clients connect to a remote server over Streamable HTTP, authenticating with a Bearer header that carries the same ak_ project key the plugins use:

# MCP clients join the same project with two values:
# server: https://memory-mcp.audaxic.com/mcp   (Streamable HTTP)
# auth:   Bearer ak_...                        (the same project key as the plugins)

Paste those two values where your client accepts an MCP server. Placement differs per client, so follow the MCP setup docs for the exact snippet for Cursor, Windsurf, or Claude Desktop. Because the Bearer key identifies the project, the MCP client reads and writes the same memory as the three plugins. A convention stored by Claude Code in the terminal is retrievable by the agent inside Cursor, and a gotcha recorded during a Cursor session is injected into the next Codex session start.

Two boundaries matter here. Cursor connects via MCP only — there is no Cursor plugin, so do not look for an install command for it. And REST and MCP read and write the same project memory, so mixed setups stay consistent. A CI job calling POST /add and POST /search against https://api.memory.audaxic.com with the ak_ key and the pinned X-Api-Version header shares state with every interactive agent on the project.

Extend the verification from the previous section to each MCP client you add. Store a fact in a plugin session, retrieve it from the MCP client, then write one back and retrieve it from a plugin. A failure in one direction means one misconfigured key. Fix that client's Bearer value and re-run the check before trusting it with real tasks.

Keep one memory clean as you alternate

A shared memory accumulates drift faster than a single-tool one, because three tools write to it. Audit it the way you audit code: pull GET /list with a small limit, scan the first pages for duplicates and contradictions, and correct them. Two competing facts force every future search to return both and make the next agent guess, regardless of which tool it runs in.

Keep each entry atomic — one fact per memory. A bundled paragraph covering the test command, the layout decision, and the staging quirk cannot be corrected piecemeal; three separate facts can. When a decision changes, correct the single fact with PUT /update. When a rule expires — the migration landed, the quirk was fixed upstream — remove it with DELETE /delete/{memory_id}. Small facts also keep accounting predictable: an add request counts per memory extracted from a message batch, so one /add call extracting 5 memories counts as 5 add requests, and retrieve counting is tiered with the first 10 memories counting as one request.

Make the maintenance a session habit, not a quarterly chore. At the end of each session, state the one new thing the project should keep — the decision, the constraint, the gotcha — and let the plugin extract it. When you catch an agent acting on a stale fact, correct it in that moment with an update rather than working around it. The workaround helps one session; the update helps every future session in every tool.

Teams sharing a repo should agree on this discipline once. The shared memory guide for teams covers grouping projects into workspaces and onboarding a teammate onto the same project memory, so the cleanup habit above scales past your own machine.

FAQ

Written by Efe — Oct 11, 2026 · More articles · X @AudaxicTech