codex vs gemini-cli: a local OpenAI agent against a Gemini terminal with hosted extras

Two terminals, two model accounts

The projects look similar from a distance: install a binary or npm package, run one command, and an agent inspects files and executes shell commands. The difference is what sits behind the prompt. Codex CLI is described in its README as a coding agent from OpenAI that runs locally, and its documented path is to run codex and select Sign in with ChatGPT, using a Plus, Pro, Business, Edu or Enterprise plan. The README notes an API key is possible but requires additional setup. Gemini CLI routes to Gemini models instead. Its README lists three authentication options: Sign in with Google using a personal account or a Code Assist licence, a Gemini API key from AI Studio, or Vertex AI. The OAuth route carries a documented free tier of 60 requests per minute and 1,000 requests per day, and the README states the models include a 1M token context window. So the first decision is not about features but about which account you already hold. If your team lives on ChatGPT seats, Codex is the shorter path. If your team lives on Google Cloud or personal Google accounts, gemini-cli removes the API key step entirely.

Architecture: Rust binary against a TypeScript agent loop

Codex is written in Rust and distributed as platform-specific executables. The README lists tarballs such as codex-aarch64-apple-darwin.tar.gz and codex-x86_64-unknown-linux-musl.tar.gz, each containing a single named entry you rename to codex. There is also npm, Homebrew and a curl install script for Mac and Linux, plus a PowerShell script for Windows. That shape matters for operations: a Rust binary has no Node runtime to manage, and the standalone installer downloads from releases.openai.com by default, falling back to GitHub Releases unless you set CODEX_INSTALLER_USE_RELEASES_OPENAI_COM to false. Gemini CLI is TypeScript and installed through npm, npx, Homebrew, MacPorts or Anaconda. The README explicitly offers an Anaconda route for restricted environments, which is a real difference if your build machines cannot reach the public npm registry directly. On the other hand, gemini-cli depends on a Node toolchain, so version drift between machines is a thing you manage. Codex's rolling install endpoint is the mirror-image risk: the README does not document a way to pin the installer to a specific build, so reproducibility depends on your package manager rather than the script.

Getting each one running

For Codex, the README gives a one-line curl or PowerShell install, then codex to start. The sign-in flow is the documented recommendation, and the README points to a separate page for API key setup. The repository also mentions codex app for a desktop experience and an IDE install for VS Code, Cursor and Windsurf, so the terminal is one surface among several rather than the only one. For gemini-cli, the fastest check is npx @google/gemini-cli, which runs without a global install. Global installs go through npm, Homebrew or MacPorts, and the Anaconda path creates a dedicated environment with conda-forge nodejs before installing. After installation you run gemini and pick an authentication method. If you hold a paid Code Assist licence, the README says to export GOOGLE_CLOUD_PROJECT before starting. That is a concrete step Codex does not have an equivalent for here, because Codex's plan entitlement is tied to the ChatGPT account rather than a cloud project identifier. Both projects keep project-level instruction files: Codex reads AGENTS.md, and gemini-cli uses GEMINI.md as a custom context file. In both cases that file is the main lever over agent behaviour, and in both cases you should confirm it is being read rather than assume it.

Release channels and what you can pin

This is where the two diverge most sharply. Codex's recent releases are all rust-v0.151.0-alpha builds, published within a day of each other, and the install script pulls from a rolling endpoint. The README does not document a stable channel, a long-term support line or a rollback procedure. If your organisation needs a frozen, versioned toolchain, that is a gap you have to close yourself, for example by pinning a GitHub Release tarball and managing the binary in your own artifact store. Gemini CLI documents three channels with explicit schedules: nightly published daily at UTC 00:00 from main, preview published weekly at UTC 23:59 on Tuesdays and described as not fully vetted, and stable published weekly at UTC 20:00 on Tuesdays as the promotion of the previous preview plus fixes. Installation tags are latest, preview and nightly. The README warns that nightly should be assumed to have pending validations and issues. That is a more legible upgrade story: a team can pin latest and still get weekly movement, or pin a specific version if npm supports it. The trade-off is that gemini-cli's stable channel is only one week behind preview, so a regression that survives preview reaches stable quickly.

Tools, automation and where each is thin

Gemini CLI's README lists built-in tools that Codex's README does not claim: Google Search grounding for real-time information, web fetching, MCP support for custom integrations, conversation checkpointing to save and resume sessions, and multimodal generation from PDFs, images or sketches. It also documents a GitHub Action for pull request reviews, issue triage, @gemini-cli mentions and scheduled workflows. Codex's README excerpt is narrower: it describes a local coding agent that inspects a repository, edits files and runs commands, and points to IDE and desktop surfaces plus a separate cloud agent, Codex Web. That does not mean Codex cannot be scripted, but the README does not document a non-interactive mode or a first-party CI integration, so treat any such use as unverified. Where Codex is stronger is focus: one binary, one sign-in, no Node runtime, and a narrower surface to reason about. Where gemini-cli is stronger is reach: search grounding, MCP and CI integration are documented features rather than assumptions. The cost is more moving parts and more documented caveats about preview and nightly quality.

Licence and maintenance signals

Both repositories are Apache-2.0 and neither is archived, so the licence question is settled the same way: permissive, with the usual patent grant and notice obligations, and no copyleft reach into your own code. Maintenance is where you have to read the facts table rather than the marketing. Both projects show a last push of 2026-09-17, two days before today, so neither can be described as abandoned, and both are still shipping: Codex through alpha builds dated 2026-08-29, gemini-cli through nightly builds dated the same day. The difference is what those pushes mean. Codex's release feed is dominated by alphas, which is a reason to skip it if you need a frozen toolchain. Gemini CLI's feed in the same window is nightly builds, but the README documents a weekly stable promotion, so the nightly tag is not the only thing on offer. Neither repository's README documents a support window, a deprecation policy or a security response process, so if you need those commitments you will not find them stated here. Note also that the two projects share a licence but not a governance model: Codex is published by OpenAI and gemini-cli by Google, and the READMEs describe different account and quota regimes rather than a common one.

Choosing for concrete scenarios

A solo developer with a ChatGPT Plus subscription who works entirely in a terminal should start with Codex: the sign-in is the documented path, the binary has no runtime dependency, and the alpha cadence is tolerable for one machine. A developer without a ChatGPT plan who wants to try an agent today should start with gemini-cli via npx, because the OAuth route needs no API key and the README states a free tier of 60 requests per minute and 1,000 per day. A platform team that must ship a pinned agent to many machines should look at gemini-cli first, since the README documents a stable tag and a weekly schedule, and should treat Codex's rolling installer as something to wrap in its own versioning. A team that wants automated pull request review and issue triage should read the gemini-cli GitHub Action documentation, because Codex's README does not describe an equivalent first-party integration. A team already standardised on Google Cloud and Code Assist licences should set GOOGLE_CLOUD_PROJECT and use gemini-cli, since that is the documented paid path. And a team that needs only a local agent with no hosted dependencies beyond the model call should weigh Codex's single Rust binary against gemini-cli's Node toolchain, then verify which one installs cleanly on their restricted build hosts.

Bottom line

Pick codex when the ChatGPT plan is already paid for and a single Rust binary in the shell is the whole requirement; pick gemini-cli when you want a documented stable channel, search grounding and a GitHub Action, or when a Google account is easier to provision than an OpenAI seat. Before committing, verify three things on your own machines: that the Codex installer resolves to the same build as your package manager, that AGENTS.md or GEMINI.md is actually being read, and that the current quota terms for whichever authentication route you chose still match what the README states, since neither README documents a rollback path if a nightly or alpha build regresses.

Sources

1. openai/codex repository
2. openai/codex README
3. google-gemini/gemini-cli repository
4. google-gemini/gemini-cli README