- All three run in a terminal and support MCP; they differ in surfaces, code licence and access model.
- Codex CLI and Gemini CLI have code under Apache-2.0, while the Claude Code repository does not declare an open-source licence.
- Gemini CLI was replaced by Antigravity CLI for some users, so check its current status before choosing.
The three tools in the title share a way of working: you start them in a project directory, describe a task, and the agent reads files, proposes changes and runs commands with your consent. The differences lie in details that seem unimportant at first and decide comfort after a month of work. This text lists only what can be verified in the documentation and repositories, with no rankings of model quality. For the idea of an agent itself, read the article How a coding agent works: the tool loop.
Overview of the basic features
| Claude Code | Codex CLI | Gemini CLI | |
|---|---|---|---|
| Maker | Anthropic | OpenAI | |
| Surfaces | Terminal, VS Code, JetBrains, desktop app, web | Terminal, IDE, desktop app, Codex Web | Terminal |
| Program code | No declared open-source licence | Apache-2.0, written in Rust | Apache-2.0, written in TypeScript |
| Installation | Native installer, Homebrew, WinGet | Installer, npm, Homebrew | npm, npx, Homebrew, MacPorts |
| Access | Subscription or Console account, also third-party providers | ChatGPT account or API key | Depends on the plan; see the Antigravity note |
| Instruction file | CLAUDE.md, or AGENTS.md without it | AGENTS.md | Described in the context and memory section |
| MCP | Yes | Yes | Yes |
The data comes from a review of the Claude Code documentation, the Codex CLI repository and the Gemini CLI repository. The licence row concerns the code of the program that runs in the terminal, not the model. The Claude Code repository in practice serves for issues and documentation, and its metadata does not indicate an open-source licence; if openness of the code is a criterion for you, check the current licence file.
A note about Gemini CLI
The Gemini CLI repository README carries a warning that is easy to miss: for users without a paid plan and for Google One users, Gemini CLI was replaced by Antigravity CLI on 18 June 2026, and the tool itself is not optimized for the latest Gemini models. It is a good example of why, when choosing an agent, you check the maker’s current notice and not a recollection from an article written a quarter ago. If you plan to work with Google models, start from the Antigravity page pointed to in the README.
Instruction files and MCP
All three tools let you write standing project rules into a file. Claude Code uses CLAUDE.md and reads AGENTS.md when there is no CLAUDE.md at all. Codex has its own guide to AGENTS.md. The practical takeaway: if a team uses several tools, keep common rules in AGENTS.md and add a line importing that file in CLAUDE.md. The same goes for MCP: Codex describes support for MCP servers, Claude Code has documentation with a command for adding servers, and Gemini CLI lists a section on MCP servers. A server written once works in each of them, which is the main argument for an open standard.
How to choose without blind faith in rankings
Instead of asking “which is the best”, ask four questions. First, which account you already pay for or can use: access to an agent usually follows from a plan with the model’s maker. Second, which surface you need: just a terminal, an editor plug-in or an application. Third, whether the tool’s code should be open, for example for audit or modification. Fourth, how the tool copes with your project: the only honest method helps here, namely the same small, verifiable task performed in each of them and a comparison of results, time and cost.
Run such a test on your own code, with a clear success criterion, on a separate branch. Write down how many fixes you had to make by hand, how many times the agent asked for consent and whether the result passed the tests. If you want to turn this into a repeatable measurement, look at the Harness and evals hub. Remember that you are judging a set: the model, the tool and the configuration together, so changing one element changes the result.
A test on a single task, step by step
To keep the comparison from being an impression, set a fixed scheme. Choose a task with a clear criterion, for example “add field validation and a test that rejects an invalid value”. Prepare a separate branch for each tool, starting from the same commit. Give each agent exactly the same task description and the same project rules in the instruction file. Measure three things: time to a working result, the number of approvals and manual fixes, and whether the tests passed without changing their content. Finally, read the diffs as in a review of a colleague’s code. One test proves nothing, but three different tasks begin to form a picture. It is worth choosing them to differ in character: a small fix in one file, a feature touching several modules, and a diagnosis of a bug whose cause you do not know upfront. The first shows speed and working style, the second the ability to stay consistent in a larger change, the third the quality of reasoning from command output. Record observations in a simple table, because after a week impressions fade while numbers remain.
While you are at it, check how each tool treats permissions. What is a default prompt in one is sometimes an automatic mode in another, so before the first run on an important repository read the security section of the documentation and do the first trials on a copy.
Last checked: 20 October 2026. Products change quickly, and this table is a snapshot from the documentation; before a purchase decision check the makers’ current pages.