DEV Community

Cover image for Using Claude Code, Codex and Gemini CLI on the same repository
Roi Dayan
Roi Dayan

Posted on Fully Autonomous

Using Claude Code, Codex and Gemini CLI on the same repository

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.md can import another file with an @ line, so a one-line CLAUDE.md works:
  @AGENTS.md
Enter fullscreen mode Exit fullscreen mode
  • Gemini CLI: its settings can name the files it reads. In .gemini/settings.json:
  { "context": { "fileName": ["AGENTS.md", "GEMINI.md"] } }
Enter fullscreen mode Exit fullscreen mode
  • Codex: reads AGENTS.md as 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.json in the project;
  • Codex: a [mcp_servers.<name>] table in ~/.codex/config.toml;
  • Gemini CLI: an mcpServers object in its settings.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
Enter fullscreen mode Exit fullscreen mode

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.md holds the instructions; CLAUDE.md imports 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)

Collapse
 
fxdgif profile image
Fred 🍓 •

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.