Shared Memory Across Claude Code, Codex and Cursor

Choose one record that must survive a client switch

Start with a concrete handoff: you establish a convention in Claude Code, implement a feature in Codex tomorrow, then review it in Cursor. For a fictional service called Lantern, the convention might be: “HTTP errors include a request ID; use the existing error helper.” The test is whether all three agents retrieve that decision without you pasting it into each conversation.

Choose a memory service that exposes reading, searching and writing through MCP. The MCP tools specification defines discovery through tools/list and invocation through tools/call; it does not prescribe your memory record format. Inspect the service’s advertised input schemas before asking an agent to write.

For the Lantern record, store the project name, decision, rationale, owner and a reference to the repository’s error-handling guide. Make this a team record. Keep personal response preferences separate. Decide that the checked-in guide wins if recalled memory contradicts it. This gives the receiving agent a fact it can verify, rather than an unexplained preference.

Connect Claude Code over HTTP

The examples below use SPYN3’s endpoint and the local server name team-memory. For another memory service, substitute its URL. In a terminal, register the endpoint using the HTTP transport documented by Claude Code:

claude mcp add --transport http team-memory --scope user https://api.spyn3.com/agent/mcp

User scope makes this connection available across your projects on that machine. Open Claude Code, run /mcp, and complete the server’s sign-in flow. Check the connection there before attempting the Lantern handoff.

A successful add command means configuration was saved; it is not proof that authentication or a memory read succeeded. Ask Claude Code to show the available memory tools and read a harmless test record. Keep that tool result as the baseline for the other two clients.

Point Codex at the same store

Official OpenAI documentation places user-level MCP configuration in ~/.codex/config.toml. Add this table, preserving any unrelated settings already in the file:

[mcp_servers.team-memory]
url = "https://api.spyn3.com/agent/mcp"

For the endpoint’s OAuth sign-in, run:

codex mcp login team-memory
codex mcp list

The documentation also supports project configuration in .codex/config.toml for trusted projects. Choose the scope deliberately so the connection is available where you will test it. In Codex, use /mcp to inspect active servers.

Authenticate as the same person in the same workspace used for Claude Code. Ask Codex to read the baseline record explicitly. If it returns an empty search, check identity and workspace selection before changing the wording of the memory.

Add the remote server to Cursor

Cursor documents remote servers under mcpServers, using a url field. Put this in the project’s .cursor/mcp.json, merging it with any existing server entries:

{
  "mcpServers": {
    "team-memory": {
      "url": "https://api.spyn3.com/agent/mcp"
    }
  }
}

For personal access across projects, Cursor also supports ~/.cursor/mcp.json. Save the file, restart Cursor, and complete authentication when prompted. Cursor’s MCP reference documents Streamable HTTP and OAuth support; its integrations guide describes the configuration locations and restart.

In a fresh Agent conversation, request the same baseline record by name. Inspect the displayed tool arguments and response. If the server is connected but no read happens, explicitly request the memory tool. This separates a connection problem from the agent deciding that retrieval was unnecessary.

Give all three agents the same recall-and-save routine

Use this instruction in each client’s instruction mechanism, or paste it into the three test sessions initially:

This routine supplies the missing behavior between “server connected” and “decision applied.” Keep its wording consistent across clients; put the actual Lantern decision in the shared store. The separate guide to keeping agent instruction files in sync covers maintaining those local entry points.

Retrieve narrowly. An error-handling change needs the Lantern convention, not every preference accumulated during unrelated projects. Read the matching record before applying it, especially when search returns only a summary. If the repository helper has changed, resolve that discrepancy before refreshing the memory.

For saves, distinguish an accepted decision from an agent’s suggestion. Ask the agent to search for an existing Lantern record before creating another. During the initial rollout, use one designated writer and let the other clients read. This makes conflicting updates easier to diagnose while you establish the workflow.

Test the handoff with fresh conversations

Run this acceptance check with a fictional project or disposable memory. Do not paste the expected answer into the receiving conversation: that would test copying from the prompt instead of retrieval.

1. In Claude Code, save the Lantern error convention through the memory tool. Confirm that the write returned success, then read it back.
2. Start a fresh Codex conversation. Ask: “Before proposing an HTTP error response for Lantern, retrieve its shared conventions.” Verify that the tool result contains the request-ID decision and that the proposal uses it.
3. Start a fresh Cursor conversation and repeat the request. Inspect the returned record rather than relying on the agent saying it remembers.
4. Have the designated writer correct the convention to name Lantern’s current error helper. Start new receiving conversations and check that both clients retrieve the corrected record.
5. With a credential that lacks memory-write permission, attempt a harmless test save. Verify that the server rejects it and the agent reports failure.

Record which client wrote, which clients read, the retrieved record and any failure. A successful connection, successful retrieval and correct application are three distinct observations. If retrieval succeeds but the proposal ignores the decision, revise the client’s working agreement. For a larger test set, use the guide to evaluating agent memory recall.

Doing this with SPYN3

In SPYN3, an admin enables Memory & skills in Settings; it is off by default. All three clients can use context_list, context_read, context_search and remember through the workspace endpoint. Personal records use spyn3://me/memories/…; team records use spyn3://workspace/memories/…. Reading needs call:tools; memory writes need the separate write:memory key permission and are audit-logged. Optional lifecycle-hook plugins automate recall for Claude Code and Codex. Cursor can use the MCP tools explicitly. Enable the setting, then try the Lantern handoff.

Move existing preferences after the handoff works

Once the same record survives all three clients, review existing local memories in small batches. Rewrite “always do this” entries with their actual project and conditions. Move only accepted, durable facts. Keep credentials, temporary debugging output and unconfirmed hypotheses out of the imported set.

For each migrated item, choose personal or team ownership, identify the evidence behind it, and confirm that the receiving clients can retrieve it. Remove the superseded local copy after verification so an older instruction cannot silently compete with the shared record. Keep repository-owned implementation rules in version control and reference them from memory when useful.

Finally, repeat one Lantern handoff with the memory server unavailable. Require each client to report that recall failed, inspect the repository directly, and avoid claiming a preference was retrieved. Keep explicit retrieval as the fallback when automation is absent. Expand beyond the pilot only when reads, corrections and denied writes behave consistently across Claude Code, Codex and Cursor.