Giving Claude Code, ChatGPT and Codex the same project context

29 June 2026

You have probably done this dance. You explain your project to Claude Code in the terminal. Later you open ChatGPT to think through a design, and explain it again. Then Codex for a quick change, and explain it a third time. Each tool starts cold, and you are the one carrying the context between them.

It is not that the tools are bad. It is that none of them share what they know about your project.

The usual fix, and its ceiling

The common approach is per tool config. A CLAUDE.md here, an AGENTS.md there, a rules file in the editor. These help, and you should keep them. But they have a ceiling. Each one lives inside a single tool, and each is a static set of instructions rather than the live state of the work. They tell an agent how to behave, not what was decided yesterday or what is in flight today.

So you end up maintaining three slightly different copies of the truth by hand, and they drift.

One shared context instead of three private ones

The cleaner model is to keep the project context in one place, outside any single tool, and let every agent read from and write to it.

What is actually worth keeping there is narrower than people expect:

• Decisions and why they were made: the approach taken, the constraints, the things you do not want changed.
• Current focus and what is in flight.
• Open tasks that live outside any one chat.
• What was just worked on, so a fresh agent gets oriented fast.

Notice what is not on that list: the entire chat history. Dumping everything into context does not help, it just buries the signal. The goal is the relevant slice, served to whichever agent needs it.

How the agents actually reach it

This is where MCP matters. MCP is a shared way for an agent to read and write an external set of tools and data. Connect Claude Code, ChatGPT and Codex to the same MCP source and they are all reading and writing one record instead of three private ones. Open a new agent, in any of them, and it already knows the project.

That is the model Memeri is built on. You connect your agents over MCP and they share one structured memory of the project plus the visible work to do. A decision made while planning in one tool is there while building in another. A task closed by one agent is not reopened by the next.

The short version

If you take one thing from this: stop keeping the truth inside each tool, and stop re-explaining. Keep one shared, current record of decisions and work, and connect your agents to it. Whether you use Memeri or roll your own, that single change is what stops the re-explaining and the drift.