Choosing a Codex surface is less about ranking features and more about matching the tool to your working context: where you are when the task appears, whether the code lives on your machine or in a connected repository, and how you like to review changes. The four surfaces — the CLI, the IDE extension, the desktop app, and cloud tasks — share the same underlying agent, but they differ in environment, repository access, and review flow. For a broad orientation, the Codex overview is a useful map before you commit to a default.
Codex CLI: the terminal-first default
The CLI is an open-source coding agent that runs locally in your terminal, directly inside your repository. You describe a task, it reads and edits files, and it executes shell commands under a sandbox, asking for approval according to the mode you configure. Approval and sandbox behavior varies by version, so check your current settings.
The CLI shines when you are already living in the shell: quick fixes, refactors while debugging, git-heavy chores, or work on remote machines over SSH. Review happens in the terminal — you inspect diffs and approve or reject actions as they occur. It also reads project-level instructions, which makes it consistent with your repo’s conventions.
Codex IDE extension: edit and review in place
The IDE extension brings Codex into Visual Studio Code and compatible editors. You delegate tasks from a side panel, watch proposed edits land in your workspace, and accept or reject changes per diff, right next to the code you are writing yourself.
This surface fits feature work that interleaves agent effort with manual coding — you keep your editor, debugger, and extensions while offloading chunks of the implementation. The review flow is the strongest argument: changes appear where you would have made them, so evaluating them is part of your normal editing loop.
Codex app: a desktop home base
The Codex app is a standalone desktop application that gives agent work a graphical home. Depending on version and platform support, it lets you run and monitor multiple local agent sessions side by side and, where supported, ties into cloud tasks so one window can hold both local sessions and delegated work.
Choose the app when you regularly juggle several tasks at once and want to see their status, diffs, and activity without switching terminal tabs. Platform and feature details vary by release, so verify what your installation supports before making it your primary surface.
Codex cloud: delegate and come back
Cloud tasks run in isolated environments prepared for your connected repository. You assign a well-scoped task, the agent works in that managed environment, and the changes come back for your review — typically as a diff or pull request where your setup supports it. Multiple tasks can run in parallel.
This is the surface for asynchronous, self-contained work: dependency bumps, test coverage, migrations, or a second task while you focus locally. Because the environment is managed, you don’t need a dev machine set up — but you also don’t have your local toolchain, so results deserve the same verification as any contribution.
Scenario table: matching surface to the work
| Scenario | Reach for | Why it fits |
|---|---|---|
| Quick fix or refactor while debugging in the shell | CLI | Works directly in your local repo, inside your existing tooling |
| Multi-file feature work beside your own edits | IDE extension | Diffs and approvals happen where the code lives |
| Several tasks running at once on your machine | App | One place to monitor parallel local sessions |
| Well-scoped chore you don’t want to babysit | Cloud | Runs in an isolated environment and returns a reviewable diff |
| Machine without a dev environment set up | Cloud | No local repo or toolchain required |
| Hands-on review of an in-flight branch | CLI or IDE | You need your local checkout, tests, and manual judgment |
Three decision criteria cut across every row. First, where does the context live — your machine or the connected repository? Second, does the task need your environment and real-time judgment, or can it run unattended? Third, do you want sequential focus or parallel throughput?
A switching workflow you can repeat
Surfaces are complements, not rivals, and a task can move between them. Use this checklist:
- Write the brief as text: goal, files involved, and a definition of done — independent of any surface.
- Record repo conventions in an AGENTS.md file so every surface receives the same instructions.
- Work on a dedicated branch and commit or stash before starting an agent, so the resulting diff is attributable.
- Move a task by reusing the written brief, not by paraphrasing from memory.
- Land everything through one review path: read the diff, run the tests, then merge or discard.
Reproducible example: fixing a flaky test — draft the fix locally with the IDE extension, push the branch, then hand the broader cleanup to cloud while you keep reviewing the first change. Both arrive as reviewable changes on the same branch history.
Limits, verification, and recovery
Everything above describes how the surfaces are designed to work; specific features, settings, and behavior can vary by product, account type, administrator policy, model, region, and the current documentation. Treat any gap between this description and your experience as a reason to check official sources, not a bug in your workflow.
Cloud tasks operate on the repository as connected, so unpushed local work is invisible to them — push first. Local surfaces inherit your machine’s reality: missing dependencies, version drift, and permission quirks all shape what the agent can do. Task shape matters too: exploratory, interactive work suits local surfaces, while long, self-contained chores suit cloud.
Verify every change the same way: read the diff yourself, run the test suite, and let CI arbitrate. An agent’s confidence is not a test result. Recovery is git’s job — branches, commits, and reverts bound the damage of any bad run. If a task goes sideways, stop it, reset the branch, and re-brief with a sharper definition of done. Discarding a cloud pull request costs nothing.
Security and privacy boundaries
Local surfaces can read files and run commands within their configured scope; sandboxing and approval settings control that reach, with names and defaults varying by version. Cloud tasks run in isolated environments, but consider what your connected repository contains before delegating work against it.
Keep secrets out of prompts, project files, and agent instructions; rely on your environment’s own secret management where it exists. Administrator and organizational policies can restrict available features or data handling, so what you see locally may differ from what a teammate sees. When in doubt, the surface’s official documentation is the authority — not memory, not this article.
FAQ
Can I use more than one surface on the same repository?
Yes. Local surfaces share your clone; cloud works against the connected repository. Keeping shared conventions in AGENTS.md helps them behave consistently, though exact feature overlap varies by surface and version.
Which surface should I start with?
Match your working context. Terminal-first developers should try the CLI, editor-centric developers the IDE extension, parallel-task multitaskers the app, and anyone with asynchronous, well-scoped work cloud tasks.
Do all four surfaces behave identically?
No. They differ in environment, repository access, and review flow, and some features vary by account or policy. The verification habit — reading diffs and running tests — should be identical everywhere.
How do I keep agent changes recoverable?
Work on branches, keep approval and sandbox settings deliberate, review every diff before applying, and run tests before merging. Reverting a commit or closing a pull request is always available as the last resort.