Claude Code vs Codex for Teams: A Workflow Comparison

Claude Code and OpenAI Codex do the same core job. They read a repository, edit files, run commands and propose changes. Over the past year their feature lists have grown closer together. Both now have an instruction file, project-level config, hooks, subagents, MCP support, a non-interactive mode for scripts, cloud tasks and pull request review. So the choice between them comes down to how each one handles safety, sharing settings, delegation and access, more than to any feature only one of them has.

This comparison covers those workflow questions. Model quality changes with every release, so it isn't covered here.

Claude Code vs Codex at a glance

Both tools change quickly. Check the official docs (linked at the end) before you standardise on a flag or file layout.

Getting both tools running

Anthropic recommends Claude Code's native installer. On macOS, Linux and WSL:

curl -fsSL https://claude.ai/install.sh | bash
claude

Homebrew (brew install --cask claude-code) and WinGet also work, but those installs don't update automatically.

You can install Codex with npm, Homebrew (brew install --cask codex) or an install script:

npm install -g @openai/codex
codex

Each tool asks you to sign in the first time it runs. For a fair trial, give both the same three or four real tickets from your backlog: one bug fix, one small feature, one refactor and one task that needs the test suite. Then compare the diffs, how often you had to step in, and how much reviewer time each change needed.

Project instructions: CLAUDE.md vs AGENTS.md

Every team ends up writing down the same things: how to run tests, which directories not to touch, naming conventions and commit format.

• Claude Code reads CLAUDE.md at the start of every session. You can have one at the project root, one for your own use in ~/.claude/, and more in subdirectories. If the repository already has an AGENTS.md, Claude Code can read that instead. The docs point out that CLAUDE.md is context, not enforced configuration. To block an action whatever the model decides, use a hook.
• Codex reads AGENTS.md from ~/.codex, then from each directory between the project root and your current directory, with closer files taking precedence. An AGENTS.override.md replaces the regular file in its directory. The combined files are capped at 32 KiB by default.

Because Claude Code can read AGENTS.md, a team that uses both tools can keep a single instruction file. Treat it like code: review changes in pull requests, keep it short, and delete rules the agent already follows without being told.

Permissions and safety

This is where the two tools feel most different.

Claude Code: rules and modes

Claude Code has allow, ask and deny rules for tools and command patterns. Settings can be checked into version control so every developer shares them, and each developer can still add their own. On top of the rules sits a permission mode. In default (Manual) mode it asks before most actions except reads. acceptEdits allows file edits and common filesystem commands without asking. plan reads and explores but doesn't edit source code. In auto mode, a second model (a classifier) reviews actions instead of you. From Claude Code v2.1.283, auto mode is the starting mode for interactive terminal and VS Code sessions, so if your team wants a different default, set it explicitly.

Codex: sandbox plus approval policy

Codex separates two questions. The sandbox (sandbox_mode) controls what the agent can technically reach: read-only, workspace-write or danger-full-access. The approval policy (approval_policy) controls when it stops to ask: on-request or never. The docs give this as the low-friction preset for local work:

codex --sandbox workspace-write --ask-for-approval on-request

A separate setting, approvals_reviewer, can send eligible prompts to a reviewer agent instead of you. All of these can be set in config.toml instead of on the command line.

What to standardise

Whichever tool you pick, write down a team default and commit it:

• Which commands may run without asking (tests, linters, type checks).
• Whether network access is allowed during agent runs.
• What is never allowed (production deploys, secret files, force pushes).

If every developer configures this differently, nobody can say afterwards what an agent was allowed to do.

Shared configuration and automation

Both tools have a non-interactive mode for scripts and CI:

claude -p "Summarise the failing tests in this branch and suggest a fix"
codex exec "Summarise the failing tests in this branch and suggest a fix"

codex exec runs in a read-only sandbox by default. Add --sandbox workspace-write if the job needs to edit files. For GitHub workflows, OpenAI recommends its Codex GitHub Action over installing the CLI in a shell step.

The building blocks for shared behaviour are now similar:

• Hooks. Claude Code hooks run commands at lifecycle events such as PreToolUse and PostToolUse, and a PreToolUse hook can block a tool call. Codex has hooks too, with events such as PreToolUse, PermissionRequest and Stop. They can be set at user or project level. Codex runs non-managed hooks only after you have reviewed and trusted them with /hooks.
• Subagents. Claude Code subagents are Markdown files in .claude/agents/, each with its own instructions, tool limits and context window. Codex custom agents are TOML files in .codex/agents/, each with its own instructions, model and reasoning effort. They inherit sandbox and approval settings from the parent session.
• Skills. Both tools package repeatable workflows as skills. In Claude Code, project skills live in .claude/skills/, and the older .claude/commands/ files still work.
• MCP. Both connect to external tools and data through Model Context Protocol servers, so an issue tracker or docs server can serve both.

One practical difference is how project config is trusted. Claude Code's .claude/settings.json is meant to be shared with everyone in the project. Codex loads a project's .codex/ layers (config, hooks, rules) only after the project is marked as trusted. Codex profiles let you switch between named sets of settings with --profile.

Delegation: cloud tasks on both sides

Both tools can now run work away from your laptop.

Codex Cloud runs tasks remotely. You set up an environment in which Codex inspects your repositories, installs dependencies and tests the workflow. Then you start tasks from it. Each task has its own workspace and keeps running while your computer is asleep. You review the changed files, ask for follow-ups, and commit or open a pull request.

Claude Code cloud sessions run on Anthropic-managed VMs. You can start them from claude.ai/code, the mobile app, the desktop app or the terminal with claude --cloud "<task>". Each --cloud command starts its own independent session, so you can run several in parallel. claude --teleport pulls a cloud session back into your terminal. Cloud sessions are available on Pro, Max and Team plans, and for some Enterprise seats. For local parallel work, Claude Code also supports background agents.

Things to weigh:

• Environment fidelity. Cloud tasks need your setup (dependencies, services, seed data) to be reproducible remotely. If your build only works on a developer's laptop, local sessions will be easier at first.
• Secrets and network. Both tools let you limit network access in cloud environments and add credentials for allowed services. Decide which credentials a remote environment may hold. Often the right answer is none.
• Review load. Parallel agents produce many diffs. The bottleneck moves from writing code to reviewing it.

Code review and pull requests

Codex starts a review when someone comments @codex review on a pull request, and it can review pull requests automatically once automatic reviews are enabled. Claude Code's GitHub Action responds to @claude in issues and pull requests, and its separate Code Review product reviews every PR automatically. With Claude Code cloud sessions, auto-fix can also watch a PR and push fixes for CI failures and review comments.

Agent review works as a first pass. It catches missed edge cases, tests that don't match the code and obvious security mistakes. It doesn't replace an owner who understands the system. A sensible team rule is that an agent's review can block a merge, but only a human can approve one.

Where each one fits

Choose Claude Code if

• You want detailed permission rules (allow, ask, deny) and one settings file the whole team commits.
• You want hooks that run without a separate trust step, and subagents with their own tool limits.
• You already pay for Claude plans, use the Anthropic API, or need a third-party provider in the CLI.

Choose Codex if

• You prefer safety split into two settings: a hard sandbox boundary and an approval policy.
• Your team already works in ChatGPT workspaces, where Codex is included from the Free plan up.
• You want project config and hooks to load only once someone has marked the project as trusted.

Using both

Some teams use one tool for interactive work and the other for delegated tasks, or have both review the same pull request. If you do this, keep one instruction file (Claude Code can read AGENTS.md) and one written permissions policy that you turn into each tool's config. Otherwise you end up maintaining two sets of rules that drift apart.

The workflow problem neither tool solves alone

Both tools give you a capable agent and can run several at once. Neither one gives you a team process: who owns which task, what counts as "done", when work may merge, and who approves a release. When teams run several agents, this missing layer is usually what breaks first. Two agents edit the same files, or a change is called finished without passing tests.

Some teams build that layer with scripts, worktrees and CI rules. Others use tools built on top of the agents. Atlas, for example, runs on Claude Code. Each engineer role is its own Claude Code session with a written role and its own working folder. Atlas refuses to mark work complete until it is on main or queued for its landing train, which merges finished branches and runs the project's own checks on the result. Whatever you choose, define "done" before you increase the number of agents.

Conclusion

Claude Code and Codex now offer much the same set of features, so the choice comes down to workflow. Claude Code uses permission rules and modes, and its settings are shared through a committed file. Codex splits safety into a sandbox and an approval policy, and loads project config only from trusted projects. Run both on the same real tickets for a week, write down your permission defaults and instruction file, and measure reviewer time rather than how good the output looks at first glance.