Claude Code vs Codex CLI: setup differences that matter

Claude Code vs Codex CLI compared from official docs only: install, AGENTS.md vs CLAUDE.md, permissions and sandbox, extensions, CI use, and setup changes.

Claude Code vs Codex CLI is mostly a question of configuration, not slogans: where instructions live, what is allowed by default, and how each tool behaves in a script. This comparison uses only the official docs, checked on 2026-10-10, and leaves out benchmarks. Doc details change between releases, so confirm against the linked pages. Statements marked “our inference” go beyond what the docs say.

What each tool is and how you start it

Claude Code is an agentic coding tool that runs in your terminal and other surfaces; see the Claude Code overview. The overview lists a native installer (curl -fsSL https://claude.ai/install.sh | bash on macOS, Linux and WSL), plus Homebrew and WinGet options. Run claude --version afterwards to confirm the install.

Codex CLI is OpenAI’s terminal agent; see the Codex CLI page. It offers a standalone installer (curl -fsSL https://chatgpt.com/codex/install.sh | sh), plus npm and Homebrew tabs. On first run, codex asks you to sign in with ChatGPT or another available sign-in method.

Both start the same way: cd into a project and run the command.

Project instructions: CLAUDE.md vs AGENTS.md

Claude Code reads CLAUDE.md files. Codex reads AGENTS.md files, per Custom instructions with AGENTS.md. That page describes a global file plus repository files, with nested directories able to override broader rules through AGENTS.override.md.

The two interact. According to the Claude Code memory docs, Claude reads AGENTS.md by default only when you have no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in your working directory or above it. Your ~/.claude/CLAUDE.md does not count for that check. To load both, open /config in a session and set Project instructions to claude-md-and-agents-md. The same page documents @path imports inside instruction files.

Our inference: a repository that serves both tools can keep the shared rules in AGENTS.md and let CLAUDE.md hold only Claude-specific notes, with the setting above making both load.

Permissions and sandboxing: two different models

Claude Code’s model is tiered, per the permissions docs: permission rules (allow, ask, deny) and modes such as default, acceptEdits, plan and bypassPermissions. The docs state that these rules are enforced by Claude Code, not by the model; instructions in your prompt or CLAUDE.md shape what Claude tries but do not change what is allowed. OS-level enforcement is a separate layer: the sandboxing page describes a Bash sandbox that restricts file and network access for shell commands, and the permissions page calls permissions and sandboxing complementary.

Codex splits the problem into two settings, per Agent approvals & security: a sandbox mode (what Codex can technically do) and an approval policy (when it must stop and ask). The page states network access is off by default and that, locally, an OS-enforced sandbox typically limits access to the current workspace. Interactive read-only use looks like this:

sandbox_mode = "read-only"
approval_policy = "on-request"

The same page says approval_policy = "untrusted" is retired and can prevent the client from starting, so remove it from user and project config, profiles and startup scripts. It also lists --sandbox danger-full-access and --dangerously-bypass-approvals-and-sandbox, and marks the latter not recommended.

Question Claude Code Codex CLI
What gates actions? Permission rules and modes, plus an optional Bash sandbox Sandbox mode plus approval policy
Network Governed by permission rules and sandbox settings Off by default
Where configured Settings files and /permissions config.toml and CLI flags

Extending them: skills, hooks, plugins, MCP

Both tools cover the same four extension points, with different file layouts.

  • Skills: Claude Code uses a SKILL.md per skill (skills docs; see also Claude Code skills). Codex also loads SKILL.md files, starting from each skill’s name and description (Codex skills).
  • Hooks: Claude Code hooks live in settings files (hooks docs; examples in Claude Code hooks examples). Codex discovers hooks in hooks.json or inline [hooks] tables in config.toml, for example ~/.codex/hooks.json or <repo>/.codex/hooks.json (Codex hooks).
  • Plugins: Claude Code plugins are directories with a manifest at .claude-plugin/plugin.json (plugins docs). Codex has its own plugin packaging (Codex plugins).
  • MCP: Claude Code documents MCP servers on its MCP page. Codex stores MCP configuration in config.toml, user-wide at ~/.codex/config.toml or per project in .codex/config.toml for trusted projects (Codex MCP).

Skills written for one tool are not guaranteed to work in the other; check each docs page for supported fields.

Running them in scripts and CI

Claude Code: claude -p "What does the auth module do?" runs non-interactively and exits non-zero on failure, per the headless docs. Without --bare, claude -p loads the same context an interactive session would, including hooks, skills, MCP servers and CLAUDE.md from the working directory and ~/.claude. --bare skips that auto-discovery, which the docs recommend for CI where you want the same result on every machine.

Codex: codex exec runs Codex from scripts and CI without the interactive UI (non-interactive mode). The approvals page says to use codex exec --sandbox workspace-write for non-interactive runs and that older --full-auto invocations still work as a deprecated path that prints a warning.

Which one fits which workflow

The docs do not rank the tools, so these are our inferences from the differences above:

  • If you want rules that are inspectable and committed as settings, Claude Code’s permission rules and modes are the more explicit surface.
  • If you want a default of no network and a workspace-limited OS sandbox, Codex documents exactly that as its starting point.
  • If a team already uses AGENTS.md, Codex reads it directly, and Claude Code can be configured to as well.
  • If your CI must be reproducible, use claude -p --bare or codex exec --sandbox workspace-write rather than relying on whatever each machine has installed.

What to change in your setup

  1. Put shared repository rules in AGENTS.md. If you also use Claude Code, set Project instructions to claude-md-and-agents-md in /config, or keep a CLAUDE.md for Claude-only notes.
  2. Search your Codex user and project config, profiles and startup scripts for approval_policy = "untrusted" and remove it.
  3. Pick an explicit Codex baseline: sandbox_mode = "read-only" with approval_policy = "on-request" for interactive review sessions.
  4. Commit Claude Code permission rules to shared settings instead of relying on prompts, and add hooks only for things that must happen every time.
  5. In CI, use claude -p --bare or codex exec --sandbox workspace-write, and replace any --full-auto flags.
  6. Re-check every command and setting against the linked pages before rolling this out.

FAQ

Does Claude Code read AGENTS.md?
By default only when there is no CLAUDE.md, CLAUDE.local.md or .claude/CLAUDE.md in the working directory or above it. The Project instructions setting in /config can make it read both. Source - the Claude Code memory docs, checked 2026-10-10.
Does Codex CLI have network access by default?
No. The Codex approvals and security page says the agent runs with network access turned off by default, inside an OS-enforced sandbox that typically limits it to the current workspace.
How do I run each tool in a script or CI job?
Claude Code uses claude -p for a non-interactive run, optionally with --bare for reproducible CI behavior. Codex uses codex exec. Both are documented on the official pages linked in this article.
Do I have to pick one?
The docs do not require it. Both read project files from the repository, and Claude Code can be set to load AGENTS.md alongside CLAUDE.md, so one repository can serve both. That arrangement is our inference, not a documented recommendation.