Codex is not a single terminal command but a family of compatible surfaces with a common task model but different execution boundaries. The CLI, the IDE extension, the desktop app, the cloud and direct API access essentially solve the same task - to run a controlled code change - but do it in different environments, with different file access, a different trust model and a different set of integrations. So the first question is not "which interface is nicer" but "where exactly should this work run and what will it see".
The local CLI is the point of maximum control and transparency. It is there that all launch flags, non-interactive mode, scripts and the most honest diagnostics via codex --help and /status are available. The price of control is that you must understand the shell, the sandbox and approvals: the CLI hides nothing, but it does not decide for you either. It is the base to return to when behavior on another surface seems mysterious - in the terminal you can see what is actually happening.
The IDE extension moves the same agent closer to the editor. It brings the context of the selection and open files, a short feedback loop and edits right in place, while staying local execution. Here it matters to keep the split in mind: some settings and state belong to the extension, while the agent's behavior, config and AGENTS.md are shared with the CLI. The extension is handy for pointed work next to the code, but the policy and boundaries are set by the same configuration as in the terminal.
The desktop app shifts the emphasis to parallelism and visual control: several chats and tasks at once, diff review, a built-in terminal, work with projects and execution targets (local, cloud). A separate subtlety is that the desktop app and the CLI can contain different versions of Codex. A feature that appeared in one client is not obliged to be in another at the same time, so the version of each is checked separately - for the CLI that is codex --version.
The cloud moves execution onto OpenAI's infrastructure: Codex clones the repository into a fresh environment, goes through a setup phase and works autonomously, returning the result via a branch and a PR. This environment has no local files or shell state of yours - dependencies and network access are set by the environment configuration. It is the best choice for a long task with no open computer, but the trust model here is different: the code and secrets live in the cloud, not on your machine.
It helps to gather the surfaces into a table once - where the work runs, when to choose it and what to check before starting. Below is such a map. You return to it not for beauty but for a decision: where you need full control and diagnostics - the CLI; where you need an edit next to the editor - the IDE; where several visually controlled tasks - the desktop; where autonomy in isolation - the cloud; where programmatic integration - the API and SDK. Each task has its natural surface.
| Surface | Where it runs | When to choose | What to check |
|---|---|---|---|
| Codex CLI | Locally, in an OS sandbox | Terminal workflow, scripts, review | /status, Git root, sandbox, approvals |
| IDE extension | Locally next to the editor | Edits by selection and open files | Extension version, shared config |
| Desktop app | Local and cloud tasks | Several tasks, visual diff | Client version, execution target |
| Cloud | OpenAI infrastructure | A long autonomous task via a PR | Environment, setup, network access |
| API / SDK | Your process/service | Embedding into CI and automation | Auth, limits, structured output |
Direct access via the API and SDK is no longer an interactive shell but a building block for your own automation. It is needed when Codex is embedded in someone else's process: CI, a service, an internal tool. There are separate chapters for that at the end, but the map is worth keeping in mind from the start: the choice of surface is a choice of environment and trust boundary, not of taste. The right surface saves both time and risk, and the wrong one creates extra of both.
The engineering conclusion is simple: standardize the repository contract and policy, not your favorite shell. Good AGENTS.md, config, tests and skills must work the same across several surfaces, while what is specific to one client lives separately and does not tie the whole process to itself. Then moving between the CLI, IDE, desktop and cloud stays a free choice for the task rather than rewriting the workflow from scratch each time.