Claude Code vs Codex: Two Coding Agents Compared

Claude Code and Codex are the two vendors’ answers to the same idea: an agent that reads your repository, edits files, runs commands and keeps going until the task is done. Both now run in a terminal, in editors, in a desktop app and in the cloud, and both review pull requests on GitHub. The real differences are structural. Claude Code reads CLAUDE.md and falls back to AGENTS.md; Codex reads AGENTS.md and nothing else unless you tell it to. Claude Code frames safety as permission modes that decide what needs your approval; Codex pairs an OS-enforced sandbox with an approval policy. Pick by which of those models suits you, and by which vendor’s account you already sign in with.

The surfaces, side by side

                Claude Code                     Codex
Terminal        claude                          codex
Editor          VS Code, JetBrains              VS Code, Cursor, Windsurf; JetBrains, Xcode
Desktop         Claude app, Code tab            ChatGPT desktop app, Codex
Cloud           claude.ai/code                  Codex cloud at chatgpt.com/codex
Scripts, CI     claude -p                       codex exec
GitHub          @claude, Code Review            @codex review
Chat, trackers  Slack                           Slack, Linear

In both, the local surfaces share one configuration. Claude Code’s CLAUDE.md files, settings and MCP servers work across the terminal, extensions and desktop app. Codex’s config.toml is shared by the ChatGPT desktop app, the CLI and the IDE extension. Codex’s desktop experience now lives inside the ChatGPT desktop app, where you choose Codex rather than ChatGPT for a new chat. Installing and signing in to Codex is covered in Codex CLI setup, and its surfaces in Codex app vs CLI vs IDE extension; the Claude Code equivalents are in Claude Code desktop vs CLI vs VS Code.

Instruction files: CLAUDE.md vs AGENTS.md

Codex builds an instruction chain when a session starts. OpenAI’s AGENTS.md guide↗ (opens in a new tab) describes the order: a global file in ~/.codex, then each directory from the project root down to where you are, taking at most one file per directory: AGENTS.override.md, else AGENTS.md, else any name listed in project_doc_fallback_filenames. Files are joined root first, so the one nearest your working directory wins, and the chain stops growing at 32 KiB by default.

Claude Code loads CLAUDE.md from the working directory and the directories above it at launch, and from subdirectories when it reads files there. It reads AGENTS.md as project instructions when there is no CLAUDE.md or CLAUDE.local.md in the working directory or above, and a CLAUDE.md can import it with @AGENTS.md. It does not read AGENTS.override.md.

For a repository both agents work in, put the shared rules in AGENTS.md. Either leave out CLAUDE.md so Claude Code reads AGENTS.md directly, or keep a short CLAUDE.md that imports it and adds what only Claude Code needs. If a repository already has its rules in CLAUDE.md, Codex can read that instead where a directory has no AGENTS.md:

project_doc_fallback_filenames = ["CLAUDE.md"]

The full map of files and precedence across tools is in AI context files compared.

Approval and sandbox models

Codex starts from containment. Its approvals and security page↗ (opens in a new tab) says the CLI and IDE extension use OS-level mechanisms to enforce the sandbox, with no network access and writes limited to the active workspace by default. The default Auto preset, workspace-write with on-request approvals, lets Codex read, edit and run commands in the workspace and asks before it edits outside it or reaches the network. /permissions switches to read-only. Even in the workspace, .git, .codex and .agents stay read-only. approvals_reviewer = "auto_review" hands eligible approval requests to a reviewer agent instead of you, and --yolo removes both sandbox and approvals, which OpenAI does not recommend.

Claude Code starts from the question of whether an action should need you. Its permission modes↗ (opens in a new tab) run from Manual, which asks before most edits, commands and network access, through acceptEdits and plan, to auto, where a classifier reviews actions instead of you, dontAsk for locked-down CI, and bypassPermissions for isolated containers and VMs only. Deny rules hold in every mode. A separate Bash sandbox, on macOS, Linux and WSL2, limits what an approved command can reach. How far to loosen it is in Claude Code auto-approve.

claude --permission-mode plan
codex --sandbox read-only --ask-for-approval on-request

Undo differs too. Claude Code checkpoints before every prompt and /rewind restores files it edited, though not changes made by shell commands. Codex’s docs recommend making Git checkpoints before and after a task so you can revert. In the cloud, Codex runs each task in an OpenAI-managed container whose setup phase can reach the network and whose agent phase runs offline by default; Claude Code’s web sessions run on Anthropic-managed infrastructure.

Subagents

• Claude Code: a subagent runs in its own context window with its own system prompt, tool access and permissions, and returns a result to the main session. Define one as a Markdown file with YAML frontmatter in .claude/agents for the project or ~/.claude/agents for yourself; Claude delegates to it when a task matches its description, or when you name it. How they compare with skills and plugins is in Claude Code plugins vs skills vs subagents.
• Codex: the Codex subagents documentation↗ (opens in a new tab) says current releases enable subagent workflows by default, with their activity shown in the desktop app, CLI and IDE extension. Custom agents are standalone TOML files in ~/.codex/agents or .codex/agents, and each can override settings such as the model or the sandbox, for example a reviewer kept read-only.
• Both: each subagent does its own model work, so a fan-out costs more than one agent doing the same job in sequence. Use them for work that is genuinely parallel, such as exploring several parts of a codebase.

MCP

Both are MCP clients for local stdio servers and remote HTTP servers, with browser sign-in for servers that use OAuth. Claude Code keeps servers private to you in the current project by default; --scope project writes them to a .mcp.json you commit. Codex keeps them in ~/.codex/config.toml, or in a trusted project’s .codex/config.toml, as [mcp_servers.<name>] tables.

# Claude Code
claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

# Codex
codex mcp add fenbs --url https://fenbs.ai/api/mcp
codex mcp login fenbs

Codex’s per-server options, such as enabled_tools and default_tools_approval_mode, are in Codex CLI setup, and the rest of OpenAI’s MCP support is mapped in MCP with OpenAI.

GitHub review

• Claude Code: Code Review↗ (opens in a new tab), in research preview on some plans, has several agents review a pull request in parallel and posts findings as inline comments tagged by severity. It never approves or blocks, and its check run always ends neutral. Comment @claude review to request one; tune it with CLAUDE.md or a review-only REVIEW.md. Separately, the GitHub Action answers @claude in issues and pull requests.
• Codex: Codex code review on GitHub↗ (opens in a new tab) needs Codex cloud set up for the repository. Comment @codex review, or turn on automatic reviews, and it posts a standard GitHub review that flags only P0 and P1 issues. It follows review guidance in your AGENTS.md files, root and nested.

Either makes a good first reader of a pull request the other agent wrote. A person still approves; AI agents for PR review has the routine.

Who each suits

• Your repository is already organised around AGENTS.md, shared with other tools: Codex reads it natively, and Claude Code reads it too when there is no CLAUDE.md.
• You want every command contained by default, with network off unless you allow it: Codex’s local default does exactly that. Claude Code can do the same once you turn on its sandbox.
• You want to tune how often you are asked, from every action to a classifier: Claude Code’s permission modes are built around that choice.
• You fire off many independent tasks from a tracker or chat and review them later: Codex cloud starts from the web, GitHub, GitLab, Linear and Slack. Claude Code’s web sessions start from the browser, the mobile app and Slack.
• You already pay for one vendor’s plan: Codex signs in with a ChatGPT account, Claude Code with a Claude subscription or an Anthropic Console account. They are billed differently; check each vendor’s current plans.

Running both on one repository

Plenty of teams do. The rules are short: one AGENTS.md both read, one branch or worktree per agent, one task per agent, and every result back as a pull request a person reviews. Who assigns work, how a task is claimed across tools and the order to merge are in orchestrating coding agents.

Keeping both on one board

A Claude Code transcript and a Codex chat list are each accurate about their own tool and blind to the other. fenbs gives both one list. Each connects to https://fenbs.ai/api/mcp with a browser sign-in, you tick what it may do, and every change is recorded in History under the assistant’s name on your behalf. A person can mark a planned task Pre-approved for AI; an idle agent calls fenbs_next_approved_task to take the next one, and fenbs_release_task hands it back with a reason if it cannot finish, so the two never race for the same task.