Each coding agent has days when it's the right tool. Running all three on one repository is easy; keeping them consistent is the work. This is how to share instructions and tools between Claude Code, Codex and Gemini CLI, keep their work apart, and hand tasks between them.
One set of instructions, three readers
Each agent looks for its own instructions file:
| Agent | Reads by default |
|---|---|
| Codex | AGENTS.md |
| Claude Code | CLAUDE.md |
| Gemini CLI | GEMINI.md |
Keep the real content in one file, AGENTS.md, and point the others at it:
-
Claude Code:
CLAUDE.mdcan import another file with an@line, so a one-lineCLAUDE.mdworks:
@AGENTS.md
-
Gemini CLI: its settings can name the files it reads. In
.gemini/settings.json:
{ "context": { "fileName": ["AGENTS.md", "GEMINI.md"] } }
-
Codex: reads
AGENTS.mdas it is.
Now a change to your conventions lands for all three at once. Agent-specific notes, if you have any, go in that agent's own file below the import.
The same tools for each
MCP servers are configured per agent, each in its own format:
- Claude Code:
claude mcp add <name> -- <command>, or a.mcp.jsonin the project; - Codex: a
[mcp_servers.<name>]table in~/.codex/config.toml; - Gemini CLI: an
mcpServersobject in itssettings.json.
It's the same server and the same command in three places. Write it once in a short script or a README section, so adding a server to one agent reminds you to add it to the others.
Keep their work apart
Three agents in one folder will collide. Give each task its own git worktree, a separate folder on its own branch:
git worktree add -b claude/refactor-auth ../app-refactor-auth
git worktree add -b codex/api-tests ../app-api-tests
Prefixing branches with the agent's name makes the history readable later, and makes comparing agents trivial: give two of them the same prompt in two worktrees, then diff the branches.
Give each agent the work it suits
Which agent suits which task changes with every release, so measure rather than trust a blog post (including this one). The worktree trick above is the cheapest benchmark you'll ever run: same prompt, same commit, two branches, one diff. After a week you'll know your own split.
Hand work between them
The awkward part of a multi-agent setup is the handoff: the Claude Code session finished the refactor, and now you want Codex to write the tests. Copying context between terminals by hand works, but it's where details get lost.
I build Moontors, a free desktop app for running these agents side by side, and this is the part it adds. Every session's agent gets an MCP server of Moontors' own with two tools: list_sessions and send_to_session. So you can tell your Claude Code session "ask the Codex session on the API to run its tests" in plain words; the message arrives in that session as its next prompt, and the answer comes back the same way. Each session still runs under its own permission mode.
It also runs each agent as its vendor ships it, with your own settings, skills and MCP servers, and never writes your config files. It's on macOS, Windows and Linux; the walkthrough is How to use Claude Code, Codex and Gemini CLI together.
Checklist
- [ ]
AGENTS.mdholds the instructions;CLAUDE.mdimports it; Gemini CLI's settings list it. - [ ] Every MCP server is added to each agent, from one script or one README section.
- [ ] Every task gets a worktree, and branch names say which agent did the work.
- [ ] You compare agents on your own code, not on benchmarks.
AI did the writing, I did the reading, and we both took credit.
Top comments (1)
The one-line CLAUDE.md with @AGENTS.md is the cleanest version of this I've seen, thanks.
One thing I learned handing tasks between sessions: the message alone makes the receiving agent start cold. Appending a short summary of what the sender just did, plus the files it changed with line counts (not the diff itself), made a big difference. The receiver knows where to look but its context stays small.
The tricky part is uncommitted work. If both agents share one folder, the receiver can't tell the sender's half-finished edits from its own, which is one more reason for your worktree-per-agent rule.