Before moving a team from Codex to Claude Code, inventory the workflows and controls that must survive the change. Native import may copy useful configuration. It doesn’t prove equivalent permissions, working integrations or accepted code. Test those outcomes on a representative repository, then make a documented go/no-go decision.
This checklist is for engineering and IT leaders assessing a team move, not an individual installing another coding assistant. For tool selection, start with our Codex alternatives comparison.
Vendor documentation checked October 19, 2026. The worksheets and tests below are our recommended assessment method, not results from a completed customer migration.
Check native import before planning manual conversion
Start with the vendor’s supported path, then assess what it leaves unresolved. Anthropic’s command reference documents importing Codex configuration into Claude Code. Covered asset types include instructions, MCP servers, commands, subagents and skills. A preview option shows the proposed work without writing changes.
The reference requires Claude Code v2.1.213 or later and lists provider-route restrictions. Don’t assume the feature exists in every enterprise deployment. Record the installed version, authentication route and available import scope in the assessment.
Have an authorized administrator preview the candidate configuration in a disposable copy of an approved repository. Save the proposed change list, then classify each item:
- Reusable: the target can use it, and the required behavior has been verified.
- Needs adaptation: the concept carries over, but configuration or behavior differs.
- Retain as evidence: needed for audit or continuity, not established as executable target state.
- Unresolved: unavailable, unsupported or not yet tested.
An imported item stays unverified until its acceptance test passes. A configuration preview isn’t evidence that credentials, organization policy or hosted automation have moved.
Inventory the workflow, not just the repository files
Make one inventory entry per recurring engineering workflow. For example, “propose a tested dependency update” is more useful than “uses Codex.” Record who reviews the result and which systems it touches.
Separate local work from hosted work. A developer’s terminal, IDE session and cloud task may reach different files, networks and credentials. Passing a local test doesn’t approve the hosted version.
Use this worksheet before estimating the migration:
| Asset or dependency | Evidence to collect | Target decision and acceptance check |
|---|---|---|
| Instructions and task conventions | Versioned files, scope and representative task inputs | Identify what loads in Claude Code; check nested and conflicting instructions |
| Skills, commands and subagents | Approved versions, dependencies, owners and required tools | Preview supported import; run the intended task and check tool access |
| Hooks and automation | Trigger, script, execution environment and failure behavior | Rebuild where required; test both intended behavior and failure handling |
| MCP connections | Approved endpoint, transport, credential owner and permitted operations | Confirm connectivity separately from allowed, denied and revoked operations |
| Client and device policies | Effective requirements on each supported machine and client | Recreate the required control outcome; verify enforcement rather than copying a filename |
| Hosted tasks and CI | Repository access, environment setup, secrets references and triggers | Assess as a separate runtime; prove checkout, tests, review and controlled delivery |
| History and audit evidence | Retention requirement, authorized archive location and accountable owner | Preserve required records; don’t assume old sessions become executable target history |
| Seats, usage and support | Current agreement, usage reports, support needs and renewal dates | Compare the intended plan and total operating effort before retiring access |
Keep credentials out of the worksheet. Record the secret-management reference and responsible owner, not the secret value. Source-system access must remain limited to the approved pilot resources.
If the wider project also moves employee ChatGPT workspaces, use the separate company ChatGPT-to-Claude assessment. Coding-client migration doesn’t establish that company GPT workflows or API applications have moved.
Map control outcomes before translating settings
Instructions are guidance; enforced controls determine what an agent can actually do. Treat “don’t deploy” in a project file differently from a technical restriction that blocks a deployment.
OpenAI’s managed configuration documentation distinguishes administrator-enforced requirements from configurable defaults. Support varies by client and execution environment. Preserve that distinction when defining the Claude Code target.
For every required control, write a plain-language outcome. Examples include “only the company identity can sign in” or “this runtime cannot access production.” Then identify the mechanism and owner that enforce it in each setup.
Don’t equate similarly named permission or sandbox modes. Anthropic’s security documentation separates permission prompts, sandboxing and cloud execution controls. Keep repository protection, endpoint controls and downstream access restrictions independently enforced.
Confirm which instructions actually load
Anthropic’s memory documentation describes direct AGENTS.md support and its version requirements. By default, a relevant CLAUDE.md or CLAUDE.local.md changes whether AGENTS.md loads. The documentation also describes explicit import and instruction-selection options.
Check the actual files loaded for the pilot. Include a repository with nested instructions if your team uses them. A successful import or matching filename doesn’t prove equivalent scope, precedence or adherence.
Keep MCP connectivity and authorization separate
A client reaching an MCP server doesn’t prove that the correct employee permissions apply. Test who the tool authenticates as, which operation is allowed and what happens after access is removed.
Anthropic’s managed MCP documentation distinguishes server configuration, allowlists and restrictions on who can expand those allowlists. A project connection file alone isn’t an organization-wide enforcement policy.
For the Claude-side rollout mechanics, reuse our managed settings and SSO guide. The migration assessment should reference that implementation work, not silently assume it’s complete.
Run a small acceptance pilot with explicit failure cases
Choose a disposable repository or approved test copy, synthetic data and non-production services. Give both tools the same starting revision, task description and acceptance criteria. Compare required control outcomes, not necessarily identical configuration files.
The following tests are recommendations, not reported customer results:
| Test | Pass condition to agree before running | Evidence to retain |
|---|---|---|
| Approved engineering task | A reviewer accepts the change and the agreed tests pass | Starting revision, output diff, test results and review decision |
| Restricted file or operation | The designated control blocks the prohibited action | Test identity, effective policy, attempted action and enforcement result |
| Unapproved MCP server | The client cannot use a server outside the approved policy | Server configuration, active policy and connection result |
| Allowed versus denied tool call | The permitted identity succeeds; the restricted identity is denied | Caller identity and tool/downstream outcome for both users |
| Revoked access | New attempts fail within the organization’s agreed interval | Revocation time, retries, credential scope and resulting records |
| Hook or dependency failure | Failure follows the agreed policy without an unintended action | Controlled failure, resulting behavior and remediation owner |
| Local versus hosted execution | Each approved runtime passes its own required checks | Separate environment configuration and test record |
| Rollback | The team can resume the accepted source workflow | Preserved configuration, recovery steps and owner sign-off |
A verbal refusal from an assistant isn’t proof of technical enforcement. Check the underlying tool or system result. Stop the pilot if a mandatory control fails; don’t compensate with a higher average score.
For an illustrative dependency-update workflow, a passing patch is only the first result. Also verify that the client cannot use a production credential or publish a release without the required approval.
Define a small set of representative tasks before running either tool. Include failed attempts and rework in the evaluation. Don’t discard inconvenient results or generalize one successful task into a company-wide productivity claim.
Compare cost per accepted task, not just the seat price
Record subscription charges, usage charges, infrastructure and temporary overlap between tools. Track review, correction and administration time separately from cash spending. Released engineering capacity isn’t automatically a payroll saving.
Use the same task mix and acceptance standard for each candidate. Report failed attempts and rejected changes alongside successful work. A low token bill is unhelpful if reviewers spend longer correcting the result.
Keep quoted plan rates separate from displayed session estimates. Anthropic’s cost guidance explains how session token-cost figures differ from subscription billing. Use your actual agreement and invoices for the purchasing decision.
This assessment can conclude that coexistence is preferable. Keeping Codex for one workflow and Claude Code for another may avoid an unnecessary rebuild, but adds administration and policy-maintenance work.
Leave with a go/no-go decision and an owner for every gap
The final package should let an engineering leader approve, narrow or stop the move:
- An asset inventory with owners, source evidence and proposed target treatment.
- A record of native import scope, reviewed changes and unsupported dependencies.
- A control-outcome matrix with allowed, denied and revoked-access evidence.
- A same-task comparison covering accepted output, rework, cash costs and operating effort.
- A phased rollout and rollback plan, with explicit retirement and retention decisions.
Proceed only when mandatory checks pass and the accountable owner accepts remaining limitations. Keep the source configuration and required records until the agreed retention and rollback conditions are satisfied.
ASCENDING Inc builds and maintains the open-source Jarvis project. If you’re evaluating Jarvis Crosswalk for an assessment, confirm its current collection coverage, deliverables and delivery scope with our team.
Don’t assume an available automated scanner or a tested migration path. Native import and the evidence checks above still matter. Discuss a bounded assessment with ASCENDING using one workflow and its unresolved gaps.
References
- Anthropic: Claude Code command reference
- OpenAI: Managed configuration
- Anthropic: Claude Code security
- Anthropic: How Claude remembers your project
- Anthropic: Managed MCP configuration
- Anthropic: Manage costs effectively
Questions before moving a team from Codex to Claude Code
What should our team check before moving from Codex to Claude Code?
Inventory the workflows, repositories, instructions, integrations, credentials and policies your team depends on. Preview native configuration import where available, then verify the target behavior on a disposable repository. Require evidence for allowed work, denied operations, revoked access, operating cost and rollback before a wider rollout.
Can Claude Code import a Codex setup?
Anthropic documents a native import feature for Codex configuration, including instruction files, MCP servers, commands, subagents and skills. Availability depends on the client version and provider route. Preview its scope and review the resulting changes; imported configuration does not establish equivalent permissions, identity controls or workflow results.
Do AGENTS.md instructions work in Claude Code?
Current Claude Code supports AGENTS.md in documented versions and configurations, but loading and precedence differ. A CLAUDE.md or CLAUDE.local.md can change which instructions load. Check the active files on the actual client version instead of assuming the same filename produces the same behavior.
Does importing MCP configuration preserve company access rules?
No. A server connection and permission to perform an operation are different checks. Verify the approved server policy, the identity used by each tool, downstream permissions and revocation behavior. Reauthenticate through an approved route, and keep secrets out of migration worksheets and source control.
Do we need to replace Codex for the entire company at once?
No. Start with a bounded team and representative repository while preserving the accepted source workflow. Expand only when the owner accepts the evidence and unresolved gaps have a treatment. Coexistence can be a valid outcome, provided both clients have clear owners, policies and costs.
