Comparison

Codex vs Claude Code: which should your company standardise on?

Book a 30-minute call For engineers Run a fair pilot

1AYM is an OpenAI Select Partner. Its founder holds personal Claude certifications. 1AYM is not an Anthropic partner.

Written by Tayyeb Mahmud, founder and Principal Architect. Claude Certified Architect – Professional · LinkedIn profile of Tayyeb Mahmud

Vendor facts checked on 29 September 2026 against each vendor’s own pages.

The short answer: standardise the rules, not the tool

Both products do the same core job. They read a code repository, change files, run commands and hand a change back for review, and both run in a terminal, in an editor, in a desktop app and in the vendor's own cloud. The differences that matter to a business sit elsewhere: where the code runs, how an administrator enforces policy, which cloud provider carries the model traffic, and which vendor you already buy from.

Our view, from using both in our own engineering work: choose the one that fits your existing contract and your security model, write the instructions and rules once, and let a team use the other where a pilot on your own code shows it does the better job.

Sources: [1] [9]

What each tool is

Both are described here from the vendors' own documentation, read on 29 September 2026. Neither vendor's description is a measurement, and the model line-ups behind both change often.

Claude Code (Anthropic): Anthropic describes it as an agentic coding tool that reads your codebase, edits files, runs commands and works with your development tools. It runs in the terminal, in VS Code and JetBrains editors, in a desktop app and on the web, and it can run in CI through GitHub Actions or GitLab. Most surfaces need a Claude subscription or an Anthropic Console account; the terminal, VS Code and JetBrains clients can also run through third-party cloud providers.
Codex (OpenAI): OpenAI's coding agent, now documented as part of ChatGPT. It runs as the Codex CLI in a terminal, as an editor extension, in the ChatGPT desktop app, and as Codex cloud, which runs tasks in isolated cloud environments started from the web, GitHub, GitLab, Linear or Slack. It is included in ChatGPT plans from Free upwards, or it can run on an API key, which leaves out the cloud features.
What they share: Both read a project instruction file, both load skills written in the open Agent Skills format, and both connect to outside tools through MCP, run hooks and use subagents. That shared ground is why moving between them is cheaper than it used to be. Each is what we call an AI harness: the vendor builds and maintains it, and the instructions, skills and rules on top are the company's to write.

Sources: [1] [2] [3] [9] [10] [11] [13] [14] [18]

What switching costs

The licence is the small part. Both vendors list their entry business seat at US$20 per user a month billed annually, or US$25 billed monthly: a Claude Team standard seat and ChatGPT Business. The larger cost is people's time to move and re-check what your teams have built around the tool: instruction files, skills, permission settings, hooks and connections to internal systems.

That cost has fallen, because each tool can now import the other's setup. OpenAI's import flow, in the Codex CLI and the ChatGPT desktop app, reads a Claude Code setup and brings across instruction files (as AGENTS.md), settings.json (as config.toml), skills, plugins, MCP server settings, hooks, slash commands (as skills), subagents, project memories and recent chats; the CLI takes up to 50 chats from the last 30 days. It leaves the Claude Code setup unchanged.

In the other direction, Claude Code's /import command, from version 2.1.213, reads a Codex setup on the same machine. It appends a one-time copy of instruction files such as AGENTS.md to the matching CLAUDE.md and brings across MCP servers, commands, subagents and skills, and a dry run shows what it would change before it writes anything. When /init finds Codex configuration, it offers to run the import. The command is not available when Claude Code runs through Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry or Claude Platform on AWS. Without it, Claude Code still reads a repository's AGENTS.md when the repository has no CLAUDE.md.

What does not move by itself is judgement. OpenAI's own import guidance says to review imported permissions and tool restrictions, MCP servers that use custom authentication, hooks whose behaviour may differ, and prompts that depend on arguments or file paths. The two permission models are also built differently, so an administrator's policy has to be rewritten rather than converted, whichever way the move goes.

Sources: [2] [8] [12] [18] [20] [24]

Usage on top of seats

Usage on top of seats is harder to compare. Anthropic publishes one reference point for Claude Code: across enterprise deployments, an average of about US$13 per developer per active day and US$150 to US$250 per developer per month, with 90% of users below US$30 per active day. OpenAI's Codex pricing page describes usage as plan limits, then credits priced per million tokens, with typical credits per message for each model, and gives no per-developer figure. Neither is a forecast for your team. A two-week pilot on your own repositories is.

Prices and plan limits change. Both pricing pages were read on 29 September 2026, in US dollars; check both on the day you buy.

For the plan-by-plan prices at business and enterprise level, see our ChatGPT Enterprise vs Claude Enterprise guide, which compares every tier on the vendors' own pricing pages.

Sources: [7] [8] [18]

Governance: where each tool keeps its controls

For a security reviewer the useful question is not which tool is safer in general. It is where the controls live, who can change them and what happens by default.

Default behaviour: Claude Code's Manual mode asks before most edits, commands and network access. From version 2.1.283 its starting mode in the terminal and VS Code is auto mode, in which a second model reviews actions instead of a person. A reviewing model is still a model, and our pattern note sets out why a model should not be the only gate on a consequential action. Codex runs with network access off by default, and for a version-controlled folder OpenAI recommends its Auto preset, which edits and runs commands inside the project and asks before going outside it or onto the network.
Organisation policy: Claude Code applies a managed settings file above every user and project setting; it can deny specific file reads and commands, turn off the mode that skips all checks, and deploy approved MCP servers. Codex enforces administrator requirements that users cannot override, covering the approval policy, the sandbox, web search, managed hooks and which MCP servers people can switch on.
Where the code runs: Both work on the engineer's own machine, and both offer sessions that run in the vendor's cloud: Claude Code on the web, and Codex cloud, whose environments are isolated containers with the agent working offline unless internet access is switched on.
Which cloud carries model traffic: Claude Code can route through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry. Codex's local clients can use OpenAI models through Amazon Bedrock with AWS authentication, with OpenAI's hosted API out of the request path, and its configuration documents an Azure OpenAI provider. If your data policy names a cloud provider, this can settle the question on its own.
Training on your data: Both vendors' business plans state no model training on your content by default: Claude's Team plan and ChatGPT Business.

Sources: [1] [4] [5] [6] [8] [11] [15] [16] [17] [18] [19]

A decision guide in five questions

Answer these in order. The first firm answer usually decides it.

Do you already buy ChatGPT Enterprise or Claude Enterprise?: Start with the tool inside the contract you have. Sign-on, audit, retention and procurement are already settled there, and both tools sit inside those plans.
Does your data policy name a cloud provider?: If model traffic must stay with Google Cloud, Claude Code is the one with a documented route there: as of 29 September 2026, OpenAI's Codex configuration docs list no Google Cloud provider. Both document a route through Amazon Bedrock, and on Bedrock both lose their cloud features. Codex runs locally only, without Codex cloud, its GitHub, Slack and Linear cloud integrations, web search or admin features such as SAML SSO, SCIM and the analytics API. Claude Code runs without cloud sessions, Claude Code in Slack, Remote Control, web search, admin features such as the analytics dashboard and server-managed settings, or the /import command. Both can use Microsoft's cloud: Claude Code through Microsoft Foundry, Codex through an Azure OpenAI provider.
Do you want agents working unattended in the vendor's cloud?: Both offer it. Read how each isolates the environment, handles secrets and controls internet access before you allow it on a real repository.
Is the engineering team already split between the two?: Then do not force a switch. Keep the instructions in one AGENTS.md, keep skills in the shared format, and hold one written permission policy per tool. Our rollout guide for Codex and Claude Code covers that operating layer in full.
Which one does better work on your code?: A pilot answers that, not a brochure. Run both for two weeks on one repository that ships often, and count merged changes, reviewer time and rework. The next section sets out how to keep that comparison fair.

If you keep both, the skills and rules are what you end up maintaining twice. Writing them once is the point of 1AMS, our product for building skills once and deploying them to each vendor's own tools, offered as a guided pilot. The engagement that puts the whole layer in place is AI harness and platform engineering, and engagement file D-01 shows what re-architecting a skills estate on a production platform changed.

Sources: [6] [8] [11] [15] [17] [18] [19] [20] [24]

How to run a fair pilot of your own

Vendor documentation says what each tool can do. It cannot say how each behaves on your code, with your reviewers. A two-week pilot can, as long as both tools get the same conditions.

The same starting point: Pick one repository that ships often and has tests you trust. Keep one AGENTS.md as the instructions for both tools and no project CLAUDE.md, so both start from the same file.
The same conditions: Run each tool on your business plan with its default model, give both the same written task, and fix a time limit and a cap on follow-up messages before anyone starts.
A clean configuration: Start each run without anyone's personal instructions, skills, MCP servers or plugins, and with memory features off, so one engineer's setup does not decide the outcome.
A blind review: Have a reviewer judge each change as a diff, with commit messages and attribution lines removed, before they learn which tool wrote it. Claude Code adds a Co-Authored-By line to its commits by default.
What to count: Merged changes, reviewer minutes to a merge decision, the rework the reviewer asked for, and usage as each tool reports it. Write down the tool versions and the dates.

Check the controls as well as the code. Give each tool a task that leads towards something your policy forbids, such as reading a secrets file or pushing to a protected branch, and record whether it asked first, was blocked or went ahead. Two weeks on one repository will not settle which tool is better in general. It will show which one suits your team on your code, which is the decision you are making.

Sources: [2] [5] [13] [16] [21] [22] [23]

For engineers: configuration, controls and a clean pilot setup

Instruction files

Claude Code reads CLAUDE.md, .claude/CLAUDE.md and CLAUDE.local.md up the directory tree, plus the user's ~/.claude/CLAUDE.md and any managed-policy CLAUDE.md. It reads AGENTS.md only when none of those three project files exists in the working directory or above it, unless the Project instructions setting says otherwise. Reading AGENTS.md directly needs Claude Code 2.1.277 or later.

Codex reads AGENTS.override.md or AGENTS.md from its home directory, then from the project root down to the working directory. Files are joined root first, so the nearest file wins, up to 32 KiB by default (project_doc_max_bytes).

For a repository both tools use, keep AGENTS.md as the source. Either leave out a project CLAUDE.md, or have CLAUDE.md import AGENTS.md.

Sources: [2] [13]

What each import maps

Codex, from Claude Code: instruction files to AGENTS.md. settings.json to config.toml. Slash commands to skills. MCP configuration, hooks and subagents to their Codex equivalents. Project memories to memories. The CLI command is /import; it is not available during a running task, in a remote session or while connected to a local app-server daemon.

Claude Code, from Codex: /import codex (the same command also takes gemini or cursor). Instruction files such as AGENTS.md are appended once to the matching CLAUDE.md; MCP servers, commands, subagents and skills come across too. --dry-run previews without writing anything and --yes skips the interactive picker; with -p it lists what it found and prints the command that confirms the import. It needs v2.1.213 or later, and it is not available on Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform on AWS, through a Claude apps gateway, or with feature-flag fetching turned off. /init offers it when it finds Codex configuration.

Sources: [2] [12] [20]

Skills in both

Both follow the open Agent Skills format: a directory with a SKILL.md file and optional scripts and references. Codex requires a name and a description in the frontmatter. Claude Code adds frontmatter fields of its own, so for a skill that must load in both, keep the frontmatter to the six fields in the open specification.

Sources: [3] [14]

Permission models

Claude Code has permission modes: default (shown as Manual), acceptEdits, plan, auto, dontAsk and bypassPermissions. Allow, ask and deny rules sit on top, and deny rules apply in every mode.

Codex combines a sandbox mode (read-only, workspace-write or danger-full-access) with an approval policy such as on-request. The untrusted approval policy is retired. From Codex 0.138.0, permission profiles are the preferred way to set this.

Sources: [4] [15] [16]

Enforcement

Claude Code: managed-settings.json, an MDM profile or server-managed settings, applied above user, project, local and command-line settings. The documented example denies Read(./secrets/**) and disables bypass mode.

Codex: requirements.toml (for example /etc/codex/requirements.toml) constrains approval policy, sandbox mode, permission profiles, web search, managed hooks, allowed MCP servers and plugin sources. Managed config.toml values are defaults that users can override; requirements are not.

Sources: [5] [16]

Setting up a clean pilot

Give each run a new, empty configuration directory: CLAUDE_CONFIG_DIR for Claude Code, CODEX_HOME for Codex. Claude Code keeps settings, session history and plugins under its directory, and Codex reads a user-level AGENTS.md from its home, so an empty one keeps personal setup out of the run.

Claude Code's auto memory is on by default and shared by every worktree of the same git repository; CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 turns it off. Codex's local memories are off by default. Do not run either import command during the pilot, or the second tool starts from the first tool's setup.

For the blind read, export the diff from the starting commit to the final working tree, untracked files included and tool directories such as .claude/ and .codex/ excluded. Strip commit messages and trailers, including Claude Code's default Co-Authored-By line, before the reviewer sees it.

For the policy check, put the same restrictions in each tool's enforcement file, managed-settings.json for Claude Code and requirements.toml for Codex, and record the tool version, model, plan and operating system for every run. Claude Code reports usage with /usage.

Sources: [2] [5] [7] [13] [16] [21] [22] [23]

Sources

Frequently asked questions

Is Codex or Claude Code better for a business?

Neither in general. For a business the deciding factors are the contract you already hold, where your policy lets code and model traffic run, and how each tool behaves on your own repositories. Both list their entry business seat at the same price. Run both on one repository for two weeks and compare merged changes, reviewer time and rework.

Can we move from Claude Code to Codex without starting again?

Largely, yes. OpenAI's import flow in the Codex CLI and the ChatGPT desktop app brings across instruction files, settings, skills, plugins, MCP settings, hooks, slash commands, subagents, project memories and recent chats, and leaves the Claude Code setup unchanged. OpenAI says to review permissions, custom-authenticated MCP servers, hooks and argument-dependent prompts after importing.

Can we move from Codex to Claude Code?

Largely, yes. Claude Code's /import codex command, from version 2.1.213, appends a one-time copy of instruction files such as AGENTS.md to CLAUDE.md and brings across MCP servers, commands, subagents and skills; a dry run shows what it would change first. It is not available when Claude Code runs through Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry or Claude Platform on AWS. Without it, Claude Code still reads a repository's AGENTS.md when there is no CLAUDE.md. Permission and administrator policy have to be rewritten, because the two tools model permissions differently.

Why is the comparison written by an OpenAI Select Partner?

Because that is who we are, and it is stated at the top of the page for that reason. The facts here come from each vendor's own documentation, dated and listed in the sources, so anyone can check them. The pilot section shows how to compare both tools on your own code without relying on our word.

Further

ChatGPT Enterprise vs Claude Enterprise · Plan-by-plan prices and how to choose at company level.
How to roll out Codex and Claude Code · The operating layer around either tool: skills, permissions, review gates and CI.
AI harness & platform engineering · The engagement that puts that layer in place, sold as AI Engineering Transformation.
1AMS by 1AYM · Build skills, agents and plugins once, then deploy them to each vendor's own tools.
What is an AI harness? · Who builds the runtime, and what the company still has to write.
Engagement file D-01 · A skills estate on a production platform, and what re-architecting it changed.

Choosing, or running both?

Half an hour is enough to tell you which way we would go on your repositories, what the operating layer would take, and roughly what it would cost.

Book a 30-minute call tayyeb@1aym.com See the engagement files

Last reviewed 29 September 2026 · 1AYM