Claude Code and Codex: what a local MCP test shows about Memory continuity

Switching between Claude Code and Codex raises a practical question: can a Memory saved through one client be inspected in a fresh session through the other? We tested that narrow case with explicit MCP calls against Cairn (cairn.ink)'s source-run local preview. The result supports source continuity in this setup. It says nothing about what either client will capture in the background or recall from a natural-language question.

What we ran

On 2026-11-08, the clients were Claude Code 2.1.319 and Codex 0.166.0. The local MCP source was pinned to ad274b6, with a fresh synthetic database and project-scoped fixtures.

We saved one harmless synthetic preference with Claude Code, ended that session, then used a new Codex session to read the matching source. We repeated the direction from Codex to Claude Code with a separate fixture. Both directions returned the expected source. For each wrong-project control, we reused that direction's positive project-scoped fixture and configured the local server with another existing opaque project ID. Both source lists were empty. The receiving prompts and working directories did not contain the expected values.

These were explicit tool calls. In particular, read_memory_sources lists retained sources in the configured local scope; it does not semantically match a question or generate an answer. The pinned standalone MCP guide documents that boundary and the tools available in this source version.

A safe way to repeat it

Use a disposable local setup and substitute your own private placeholders for the database, owner and opaque project ID. Do not use a production database or real personal notes. The native clients used existing subscriptions, so a local database did not make this an offline run; no hosted Cairn write was made.

1. Pin the same source commit and start the local preview against a new synthetic database.
2. Save a non-sensitive project-scoped fixture through an explicit MCP call in client A. Keep the expected value outside client B's prompt, repo, working directory and session history.
3. End client A's session. Start a new process or session in client B, then explicitly call read_memory_sources and check the returned source and Source Receipt. An additional inspection call can be useful in a new run, but it was not part of this cross-client result.
4. Repeat with a different fixture in the other direction. For each wrong-project control, reuse that direction's positive fixture and configure an alternate opaque project ID that exists in the test setup.
5. Record the client versions, pinned source, scope, calls and outcome. Mark source-list reads separately from semantic recall.

This is source continuity in a local development preview. The local owner and project come from the server's launch settings; they are not a hosted account authentication boundary. We did not test hosted same-account access, semantic recall quality, or automatic capture and retrieval. The source docs describe a development preview, not a hosted integration.

What a source can tell you

A Memory is private and user-owned. Its Memory Scope sets where it may be recalled. A Source Receipt helps explain why the Memory exists, but a receipt cannot establish that its contents are correct or still current. The local store contract describes the inspection and scope fields in this pinned version. A Knowledge Card is a separate document; sharing one requires a separate human decision. We created no shared Knowledge Card and made no hosted Cairn write.

The useful result is modest: with this source version, these two client builds could explicitly read the same project-scoped synthetic source across fresh sessions, and the wrong-project controls stayed empty. That gives an engineer a concrete check to run before relying on continuity. It does not make local source listing interchangeable with hosted memory or model recall.

For setup and client-specific steps, read the Learn guide to sharing private memory across AI tools.