Claude Code vs Codex vs Gemini CLI: choosing an agentic coding CLI

Claude Code, OpenAI’s Codex, and Google’s Gemini CLI are all terminal-native agentic coding tools, and under the hood they run the same loop: read the relevant files, form a plan, edit code, run a command (tests, build, a script), read the result, and iterate — asking for permission at the steps that matter. This is the agentic coding pattern, not autocomplete: the tool takes multi-step actions against your real project, not just suggestions in an editor.

This space moves monthly — treat the row items as posture, not a frozen spec, and confirm current capabilities in each tool’s docs.

The agentic-coding category has exploded, and the numbers get quoted a lot — so here they are with the caveat they deserve: these are reported market estimates from mid-2026 analyses, not audited figures, and they move fast. The category has been pegged at roughly $8B in annualized revenue, with one tool holding on the order of a ~54% share, and Codex reportedly growing several-fold (around 6×) over a Jan–Apr window. AI-authored commits have been estimated at a low-single-digit percentage of public GitHub activity and climbing.

Read those as direction, not decimals. The signal worth keeping is that this is now a large, fast-consolidating market where a few tools dominate and adoption is real — not that any single share number is precise or durable. Do not pick a tool on a market-share stat; pick on fit and re-check, because the leaderboard here has reshuffled repeatedly.

Once you are past the model, the felt differences are about harness philosophy: how much the tool does before it stops to ask, how you extend it, and how it manages context. Permission models vary from "confirm every write" to broad autonomy with guardrails — this is the single biggest difference in how a tool feels, and the right setting depends on how much you trust it in your repo. Extensibility is the other axis: MCP is now common ground across all three for wiring in live tools, while higher-level mechanisms (Skills, plugins, extensions) differ in maturity and design.

Because MCP is shared, an integration you build against it tends to be reusable across tools, which lowers lock-in on the capability side. Lock-in that remains is mostly ecosystem and model: your existing cloud, your preferred model, your team’s muscle memory. That is why the honest recommendation is to run the same non-trivial task through two of them and compare the diffs and the interruptions, rather than trusting any table — including this one.

You have a real ticket — add a feature across three files with tests. Rather than argue specs, run it through two of the CLIs on a branch each. Watch three things: the quality of the diff (did it do the right thing, minimally?), the interruptions (did it ask permission at the right moments, or barrel ahead / nag constantly?), and the recovery (when a test failed, did it read the failure and fix, or thrash?). Those three tell you more than any feature grid.

You will usually find the models are all capable and the deciding factor is fit: one asks for permission in a way that matches your risk tolerance, one plugs into the ecosystem you already run, one is open enough to inspect and script around. Pick that one, wire your MCP tools in once (they port across), and re-run this bake-off in a quarter — because in this category, today’s winner is a snapshot, not a verdict.