One machine, several CLIs

Nobody decides to run four coding CLIs. You pay for one, a client's repo expects another, something new comes out and you try it on a branch, and six months later `which` returns four binaries and you have four sets of instructions in slightly different dialects. This is about making that state deliberate rather than accidental.

What actually collides

Less than you would think, and in specific places. The binaries do not collide. They have different names, they install globally, and they stay out of each other's way. The config directories do not collide either. Each one owns its own folder and ignores everyone else's. What collides is the instructions, because that is the one file that is about the project rather than about the tool — and every tool has an opinion about what it is called.

The AGENTS.md question, answered properly

The obvious move is one AGENTS.md that everything reads. It half works, and the half that does not is worth knowing before you rely on it. Codex, opencode and Qwen Code read it directly. That part is genuinely solved. Claude Code reads it only when there is no CLAUDE.md in the working directory or above it. Add a CLAUDE.local.md for your own notes and you have silently stopped it reading the shared file. Gemini CLI reads GEMINI.md until you list AGENTS.md in its settings, which you can do and most people have not. Aider reads nothing unless you pass it.

Which tool was this repo set up for

A repo tells you, if you look. A `.claude/` directory, a `.cursor/`, an `AGENTS.md` with Codex-flavoured instructions in it — those are the previous person's choice, and matching it is usually cheaper than converting it. This matters most on someone else's project. Their instructions file was tested against their tool. Reading it with a different one is fine; assuming the conventions in it apply equally is where you get surprised.

The things that do quietly go wrong

Four sign-ins. Each tool holds its own credentials in its own folder, which means revoking access in one place leaves three. Worth knowing if a laptop goes missing, and worth a note somewhere of which tools are signed in to what. Four subscriptions. Easier to accumulate than to notice, because none of them is expensive on its own. Four sets of MCP servers. The same server added to three tools is three connections and three copies of its tool definitions, one per session you start. If you only use one tool for the work that needs it, only install it there. Muscle memory. The commands differ in small ways, and the mistake is usually harmless. Usually.

A setup that holds

Pick a primary. The one you reach for without thinking, where your MCP servers and skills live and where you keep them current. Keep the others installed but bare. No global MCP servers, no accumulated skills, nothing you would miss. They exist for the projects that expect them. Write AGENTS.md, point the others at it, and check once a quarter that they are actually reading it. That last part is a one-prompt job and it is the one everybody skips.

Run the first one in each tool, in the same repo, on the same day. If the answers disagree, you have found the thing this page is about.

• Coding CLIs: the terminal as the interface
• Global or project: where config lives
• AGENTS.md: a README for your coding agent
• Browse coding CLIs