Codex cloud vs Codex CLI: which surface for which work

OpenAI ships Codex as one agent with several surfaces, and the two that do real work are the CLI (command-line interface) on your machine and Codex cloud on theirs. The cloud docs describe the split plainly; what they leave out is a rule for routing a given task to the right side. Here is the mechanism, then the rule I use.

How a cloud task runs

You configure an environment per repository: which repo, which setup steps, which tools the agent may use. When a task starts, Codex spins up a sandboxed VM (virtual machine) from that recipe, works in it, and hands back a diff or a pull request. Tasks run in the background and in parallel; you can start one from the IDE extension, watch progress, and apply the resulting diff locally. The GitHub wiring is the standout: tag @codex on an issue or a pull request and the agent picks it up from there, proposing changes “directly from GitHub.”

In contrast, the CLI reverses each of those properties. It runs in your terminal with your real environment: your installed toolchains, your local databases, your dotfiles, and your hardware. Nothing needs to be declared in advance; everything is simply there.

The routing rule

Three questions settle the routing. (1) Does the task need anything that only exists on your machine? Local model weights, a device on your network, credentials you will not upload; if so, the task belongs on the CLI. (2) Will you watch it or queue it? Interactive back-and-forth wants the CLI’s immediacy; queued batches are what cloud’s parallel background execution is for. (3) Does the work start from GitHub anyway? Issue triage and review-comment fixes flow naturally from an @codex mention; routing those through a terminal adds an unnecessary step.

My own usage is lopsided: the CLI plus scheduler-driven pipelines covers nearly everything I do, because my batch work leans on local runners and a self-hosted deploy path. Consequently, the cloud surface is worthwhile in the setup I have verified it against, the GitHub-native flow, where an issue becomes a proposed PR (pull request) without anyone opening a laptop. Teams that live in GitHub reviews will weight question (3) far more heavily than I do.

One cost note the docs do not spell out: a cloud environment is a second environment to maintain. In addition, setup steps drift from your real dev box quietly, and the first symptom is a cloud task failing on a dependency your laptop has had for months; pin the environment recipe in the repo next to the instruction file it already reads (AGENTS.md), and treat recipe drift like any other broken build.

Next run, dated for the week of 2026-07-13: route one real review-comment fix through @codex end to end and count the minutes against doing the same fix in the CLI.