Shared Memory Across AI Tools With One Vault

Somewhere in the last month, you explained the same constraint four times. Once in ChatGPT while planning, once in Claude while drafting, once in Cursor while implementing, once in Codex while cleaning up. Four tools, four independent histories, and the project context lives in whichever one you touched last.

The fix is a shared memory layer: one vault, owned by you, connected to every AI you use. Not a sync feature between vendors, since none exists, but a service that sits beside all of them. MemoryRouter is built for exactly that shape, and the setup is per-tool but small.

The shape: one vault, one connection per tool

You create a vault, then grant each tool access to it. Every connection goes through OAuth, and each one binds to exactly one vault. If you want hard separation between work and personal context, that is two vaults and two connections. Within one vault, every connected tool reads and writes the same history.

Two classes of connection exist, and knowing which is which tells you how to work with each tool:

Automatic capture. Claude Code and Codex install lifecycle hooks. They recall before prompts and store one user prompt plus one final assistant response per completed turn, without anyone asking. Compaction, resume, and fork re-inject memory, so long sessions stay continuous.

Model-directed access. ChatGPT, Claude web, Cowork, and Cursor connect through MCP. The assistant decides when to search or store, and asking directly ("search memory for the migration decision") is the reliable pattern.

Both classes reach the same vault. The platform comparison documents the exact capture boundary for each surface.

The same pattern extends past the four tools in this title. OpenClaw installs through its own plugin, and any other MCP client can join with the server URL alone. The vault does not care which client is asking; it answers the same way to all of them.

Setting it up, tool by tool

ChatGPT. Enable Developer mode in Settings, open the plugins page, and add a developer-mode app pointing at https://mcp.memoryrouter.ai/mcp. Complete OAuth, choose the vault, then pick the app from the plus menu in a chat. No key is pasted anywhere.

Claude. Add the custom connector under Customize, Connectors, paste the same URL, sign in, and choose the vault. Cowork uses the same connector. Team and Enterprise workspaces add it at the organization level first.

Cursor. Add one entry to ~/.cursor/mcp.json (or the project copy), enable the server in Settings, and sign in through the browser. Nothing secret touches the repo.

Claude Code. npx -y memoryrouter-claude init installs the hooks and prompts for your key. The key stays in your home directory.

Codex. The key goes in through stdin, then the installer sets up hooks and the MCP surface: pbpaste | npx -y memoryrouter-codex init --scope user --auth oauth --api-key-stdin on macOS.

Each of those has a full guide: ChatGPT, Claude Cowork, Cursor, Claude Code, Codex. Start with two tools, not five.

Prove it crosses tools before trusting it

The whole promise of cross-AI memory is one claim: what one tool learns, another can use. Test it with something synthetic.

In ChatGPT or Claude, ask it to store a project code phrase in MemoryRouter. Watch for the actual tool result.
Open a fresh session in a different tool on the same vault. Ask it to search memory for the phrase without repeating it.
Check that the answer came from a search result, not from politeness. A confident sentence without a tool call proves nothing.
Then flip direction: store something in Cursor and ask Claude Code for it.

If both directions work, the vault is shared correctly. If the second tool comes back empty, check that both connections chose the same vault (memory_status will tell you) before debugging anything else.

What belongs in shared memory

The bar is context that changes future answers and stays true for a while:

Decisions, with the reasoning attached.
Constraints you discovered the hard way.
Where a project stands, so the next session can pick up the thread.
Preferences that shape output: how you want drafts, reviews, and plans handled.

Keep out things that expire in a day, secrets, and anything you would not want recalled in a different context. And remember the capture difference: tools with hooks store turns automatically, while model-directed tools only keep what the model chooses to save or what you explicitly ask for. If something matters, say so in the moment.

Two boundaries close the loop. Connecting a tool never imports your old conversations; that is a separate, reviewed import workflow, and the integrations directory shows which paths support it. And a vault is only as good as what gets written to it, which is why the one-sentence habit ("save that decision") carries more of the setup than any config file.

A new machine changes nothing

The vault lives on the server, so a second laptop needs the connection and nothing else. Add the config entry or run the installer, sign in, and the memory is there: same decisions, same project state, same constraints. That is a quieter benefit than cross-tool recall, and often the first one people feel, because the alternative on a fresh checkout is the oldest ritual in software. Recreating context that already exists.

Typical recall on a vault like this lands in 300 to 500 milliseconds, so checking memory costs close to nothing. Re-explaining the project for the fifth time does not.

Create your MemoryRouter account, connect two tools, and stop writing the same brief twice.