System map: Codex vs Claude Cowork vs Claude Code

What to understand

• Think 'surfaces of one engine', not 'rival apps'. Claude Code is a single agentic engine reachable from a Terminal CLI, VS Code, JetBrains, a Desktop app, and the Web, and the same CLAUDE.md files, settings, and MCP servers work across all of them (the docs say so explicitly). The choice is which front door fits this task, because your configuration travels with you.
• Codex is the same idea on OpenAI's side: one agent across a web/cloud surface, IDE extensions, a CLI, and GitHub. So 'Codex vs Claude Code' is rarely the real question; the real question is local-vs-cloud and interactive-vs-delegated, which cuts across both vendors.
• Local surfaces are for tight feedback loops. A local CLI (Claude Code or Codex) runs against your working directory: it reads the files it needs, proposes edits, and, by default, asks before changing things or running commands, so you stay in the loop on every irreversible step. This is the fastest, safest place for exploratory or interactive work where you want to steer live.
• Cloud surfaces are for delegation. Codex Cloud runs tasks in isolated environments you configure (target repo, setup steps, available tools) and can run several in parallel; Claude Code on the Web runs sessions on Anthropic-managed cloud VMs for long-running or parallel jobs. You launch, walk away, and check back, these are delegation boards, not live conversations.
• Cloud work ends as a reviewable bundle. A Codex cloud task is designed to finish by opening a pull request from its work; Claude Code on the Web produces a result you review and can pull into your terminal (`claude --teleport`). The 'end state' of cloud work is a diff a human approves, that review gate is the whole point of delegating.
• Internet access in the cloud is a deliberate choice, not a default. In Codex cloud environments, agent internet access is OFF by default and the environment runs behind an HTTP(S) proxy; you enable network access per-environment, only when a task genuinely needs it. Treat turning it on as a decision with consequences (prompt injection, secret exfiltration, unvetted dependencies).
• Claude Cowork is the knowledge-work counterpart, and it lives where you already work. Cowork uses the same agentic architecture that powers Claude Code, but inside the Claude desktop app, alongside Chat and Code, with no terminal. It reads, edits, and creates files in folders you specify and finishes with a deliverable (a memo, a briefing, a spreadsheet with working formulas), not a code diff. Reach for it when the artefact is a document or analysis rather than a code change.
• The default safety setting differs by surface, and you should know yours cold. Claude Code CLI asks before edits/commands (normal mode); Codex's local Auto preset for git repos is workspace-write with on-request approval; Codex Cloud defaults internet OFF; Cowork shows you a plan and waits for approval before acting. Knowing the default tells you exactly which gate you are relying on, and which one you'd be removing if you flip a setting.
• The five-second routing rule: local interactive work and tight loops -> a CLI/IDE surface; long-running or parallel jobs against a repo -> cloud delegation (Codex Cloud or Claude Code Web), ending in a PR; knowledge-work deliverables -> Cowork. When two surfaces seem equally valid, pick the one that keeps the human review step closest to the irreversible action.

Deeper dive

Routing: which surface for which task

Routing decision table, match the work to the surface, not the brand. The same agent engine is reachable from many front doors; the real choice is which surface keeps a human review step closest to the irreversible action. Figures are accurate as of June 2026, defaults (especially internet/approval settings) change; verify at the cited sources before relying on them.

Sources (as of June 2026): OpenAI, Codex on the web (cloud tasks) · OpenAI, Codex cloud environments (internet off by default) · OpenAI, Codex agent approvals & security · Anthropic. Claude Code overview (one engine, many surfaces) · Anthropic. Configure Claude Code permissions · Anthropic. Cowork (knowledge work in the desktop app)

Step by step

1

Open the Codex Cloud page and read it as a delegation board

123

Visit developers.openai.com/codex/cloud and read how tasks are launched. Note the three entry points, the web interface at chatgpt.com/codex, the IDE extensions (which let you kick off a cloud task and apply the resulting diffs locally), and @codex mentions on GitHub issues/PRs, and that tasks run in background environments that can execute in parallel. Write down that a cloud task ends by opening a pull request.

HintInternalise the phrase "delegate to Codex in the cloud", cloud is for handing off work and checking back on a PR, not for babysitting a live edit loop.

On this screen

1. 1Delegation, not chat. The page is framed as 'Delegate to Codex in the cloud', tasks run in the background while you check back on results, not a conversation you steer turn by turn.
2. 2Parallel by design. One prompt is not one conversation; several isolated environments can run at once, which is the whole reason to delegate to the cloud.
3. 3Ends in a PR. The pull-request output is the point: cloud tasks are designed to finish as a reviewable diff a human approves, so your PR review becomes the safety gate.

2

Find the environment and confirm internet is OFF by default

123

On the Cloud page (and developers.openai.com/codex/cloud/environments), find the Environments concept: each cloud task needs a target repository, initialisation/setup steps, and a defined set of tools, and the environment runs behind an HTTP(S) proxy. Confirm the exact wording that agent internet access is OFF by default, and that you enable it per-environment, only when a task needs it. Note the risks the docs flag for enabling it (prompt injection, secret exfiltration, unvetted dependencies).

HintDefault to internet OFF. Treat enabling it as a named decision with consequences, write the reason next to the environment so future-you remembers why it's on.

On this screen

1. 1Environment = repo + setup + tools. The Environments UI is where the target repo, setup steps, and tool access are declared before any task runs, this is the sandbox you're handing the agent.
2. 2Internet OFF by default. The docs state agent internet access is off by default; enabling it is per-environment and deliberate, not a global default you inherit.
3. 3Internet is a switch, not a given. The 'Control internet access' card on this page is where you decide whether a cloud environment can reach the public internet at all, the proxy and isolation details live one click deeper, on the Environments page.

3

Open the Claude Code docs and confirm one engine, many surfaces

123

Go to code.claude.com/docs and read the overview. Confirm Claude Code is "available in your terminal, IDE, desktop app, and browser" and that each surface connects to the same engine, so your CLAUDE.md files, settings, and MCP servers work across all of them. Note that the Web surface runs on Anthropic-managed cloud VMs for long-running/parallel work, and that sessions are portable (e.g. start on the web, pull into the terminal with --teleport). Contrast this with Codex Cloud: Claude Code's default home is local and interactive.

HintSame engine, many surfaces, set up your CLAUDE.md and settings once and they travel with you across CLI, IDE, desktop, and web.

On this screen

1. 1Terminal is home base. The Terminal CLI is the full-featured surface and the default home for tight, interactive loops, edit, run, commit, all locally.
2. 2Web is the delegate surface. Claude Code on the Web (claude.ai/code) runs on managed cloud VMs for long-running or parallel tasks, the rough peer of Codex Cloud.
3. 3One get-started flow per surface. The Terminal / VS Code / Desktop App / Web / JetBrains tabs each set up the SAME engine, which is why the docs can promise your CLAUDE.md, settings, and connected tools behave identically wherever you open it.

4

Pin down the default safety setting on each surface

For each surface you'll use, write its out-of-the-box gate: Claude Code CLI asks before edits/commands (normal mode; auto-accept is opt-in via Shift+Tab); Codex's local Auto preset for git repos is workspace-write + on-request approval (asks before leaving the workspace or using the network); Codex Cloud defaults internet OFF; Claude Cowork shows a plan and waits for approval before acting and only touches folders/connectors you grant. Knowing the default tells you which gate you'd be removing if you flip a setting. You are done when every surface you plan to use has a one-line gate written next to it, no blanks, no "probably asks first".

HintBefore you ever enable auto-accept or cloud internet, write the one sentence answer to "what gate am I removing, and what's the worst thing it was catching?"

5

Open Cowork's page and place the document/diff line

Visit claude.com/product/cowork. Confirm Cowork lives in the Claude desktop app alongside Chat and Code, uses the same agentic architecture as Claude Code, reads/edits/creates files in folders you specify, and finishes with a deliverable (a memo, briefing, or spreadsheet) rather than a code diff. Write your own one-line rule for the document-vs-diff split, and note the two edge cases from this lesson where the file extension lies (analyst file edits that are really documents; release notes generated inside a code repo).

HintRoute on where the value and the context live, not on the file type, a spreadsheet of extracted data is a Cowork job even though it's 'editing files'.

6

Route three real tasks, then draft your cheat-sheet

Take three real tasks from your week and assign each to a surface with a one-line reason using the four factors (deliverable type, live-steer vs delegate, blast radius, default gate), e.g. "tidy a local script -> Claude Code CLI (code diff, live-steer, tiny blast radius, asks-before-edit gate)"; "refactor across a repo overnight -> Codex Cloud (code diff, delegate, ends in a PR, internet-off gate)"; "draft a stakeholder brief from notes -> Claude Cowork (document deliverable, plan-then-approve gate)". Then condense the logic into a table: Tool/surface, Best for, Where it runs, How work ends, Default safety setting, using Codex Cloud, Codex CLI, Claude Code CLI, Claude Code Web, and Claude Cowork as rows. Save it next to your operating note from Lesson 1.

HintIf two surfaces seem equally valid, pick the one that keeps a human review step closest to the irreversible action, that single rule resolves most ties.

Production prompt examples

ROLE: You are a senior staff engineer who triages incoming work onto the right agent surface. You are deliberately conservative about delegation and about removing default safety gates.

CONTEXT: The available surfaces are: Claude Code CLI (local, interactive, asks before edits), Claude Code Web (managed cloud VM, ends in a reviewable result), Codex Cloud (isolated cloud env, internet OFF by default, ends in a PR), Codex CLI (local, sandboxed, workspace-write + on-request), and Claude Cowork (desktop app, knowledge-work deliverables, plan-then-approve). I will paste one real task per line.

TASK: For each task, choose exactly ONE surface and explain the routing in terms of: (a) deliverable type (code diff vs document), (b) live-steer vs delegate, (c) blast radius, and (d) which default safety gate I am relying on.

CONSTRAINTS:
- If a task genuinely fits two surfaces, name both, then pick the one that keeps a human review step closest to the irreversible action, and say why.
- Flag any task where you'd want to CHANGE a default (e.g. enable cloud internet, turn on auto-accept) and state the specific risk that change introduces.
- Do not invent capabilities; if a surface can't do something, say so.
- Keep each answer to four lines max. No preamble.

OUTPUT FORMAT (one block per task):
Task: <restate in <=10 words>
Surface: <one surface>
Why: <deliverable + steer/delegate + blast radius + default gate>
Watch-out: <only if a default would need changing, else 'none'>

TASKS:
1. <paste task>
2. <paste task>
3. <paste task>

Common mistakes to avoid

• Treating Codex and Claude Code as rival apps to choose between, when each is a multi-surface engine and the real choice is local-vs-cloud and interactive-vs-delegated.
• Reaching for cloud delegation for quick, interactive edits that a local CLI loop would handle faster and more safely, and where you'd actually want to steer mid-task.
• Assuming cloud internet is on (or leaving it on by default). Codex cloud environments default internet OFF for good reasons; enabling it is a per-environment decision with real risk.
• Using a code-focused surface for a document deliverable that Claude Cowork is built for, or routing on file extension instead of where the value and context live.
• Flipping off a default gate (auto-accept on the CLI, internet on in the cloud) without writing down which safety check you just removed and what it was catching.
• Forgetting that cloud work is reviewed after the fact, so a sloppy PR review is the single point of failure when you delegate, the review gate is the whole reason delegation is safe.

Source conflicts to review

• Codex's local default is preset-driven: for version-controlled folders Codex recommends the Auto preset (workspace-write + on-request approvals); for non-git folders or different presets the default differs. Don't generalise one preset as 'the' Codex default, confirm the preset the docs recommend for your folder type.
• Claude Code now ships auto-accept and an 'auto mode' that can skip prompts; these are available by default unless an org disables them via managed policy. The interactive-prompt default described here is normal mode, verify your org's managed settings before assuming prompts will fire.
• Cowork's exact plan availability is described as 'all paid plans' on the product page but mobile messaging is in beta; confirm current plan/beta status on the Cowork help article before promising a capability to a learner.