Coming to Claude Code from Codex? 7 Things to Set Up on Day One

A lot of developers are running Claude Code and Codex side by side right now, or moving from one to the other. In the X data we pulled for the week to 25 October, posts mentioning Claude Code (69,609) outnumbered posts mentioning Codex (20,893) by more than three to one, and "should I switch?" threads kept coming up.

This article won't tell you which one writes better code. That depends on your repo, your tasks and the model of the month, and benchmark threads age badly. What it covers is narrower and more useful on day one: the places where Claude Code is configured differently from Codex, so the habits you bring over don't quietly fail. Every point below comes from the official Claude Code docs and the official Codex docs.

1. Preview an import before you rebuild anything by hand

Claude Code has an /import command that brings configuration over from OpenAI Codex, Google Gemini CLI or Cursor on your machine: instruction files, MCP servers, commands, subagents and skills, according to the commands reference. /init also offers it when it finds Codex or Gemini CLI configuration.

Start with a dry run so nothing gets written:

/import codex --dry-run

--dry-run previews what would come over without writing anything. Read that list, then check the rest of this article yourself, because an imported file is not the same as an imported behavior: the defaults around it are different.

2. Check which instruction file actually loads

In Codex, AGENTS.md is the instruction file. Codex reads a global one from ~/.codex, then walks from the project root down to your current directory, taking at most one file per directory, and checking AGENTS.override.md before AGENTS.md (Codex AGENTS.md docs).

Recent versions of Claude Code (v2.1.277 and later) can read AGENTS.md too, but with a rule that catches people: by default it reads your AGENTS.md only when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in your working directory or above it (memory docs). So the day you add a small CLAUDE.local.md for personal notes, Claude stops reading your shared AGENTS.md. It also doesn't read AGENTS.override.md at all.

You have two clean options:

• Set Project instructions in /config to claude-md-and-agents-md, so both load.
• Or keep one shared file and import it from CLAUDE.md:

@AGENTS.md

## Claude Code

Use plan mode for changes under `src/billing/`.

The docs recommend the import for sessions where AGENTS.md support isn't available, and note that keeping the import never makes Claude read the file twice. Use /memory to open and edit your CLAUDE.md files from inside a session.

3. Re-add your MCP servers with the right scope

Codex keeps MCP servers in config.toml, under [mcp_servers.<name>] tables, either in ~/.codex/config.toml or a project .codex/config.toml for trusted projects (Codex MCP docs). Claude Code doesn't read that file. It has its own command, with the same -- convention for stdio servers:

claude mcp add --transport stdio my-server -- npx -y some-mcp-server

The part that differs is scope. Per the Claude Code MCP docs, there are three:

• local (the default): this project only, private to you, stored in ~/.claude.json
• project: written to .mcp.json at the repo root, meant to be committed
• user: all your projects, private to you

If you want teammates to get a server, you have to ask for it with --scope project. And a project server from .mcp.json doesn't connect until someone approves it in an interactive session; claude mcp list shows it as pending until then. Keep servers with credentials in local or user scope so secrets stay out of the repo.

4. Turn the sandbox on, because it starts off

This is the biggest difference for anyone used to Codex defaults. The Codex CLI and IDE extension run model-generated commands inside an OS-enforced sandbox by default, with no network access and writes limited to the active workspace (Codex approvals & security).

Claude Code also has an OS-level sandbox for shell commands, but the sandboxing docs say it is off by default. Turn it on with /sandbox (on Linux and WSL2 it needs bubblewrap and socat, and the panel tells you if they're missing; native Windows runs commands unsandboxed).

Two defaults are worth knowing once it's on. Sandboxed commands can read most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials, unless you add denyRead rules. And the sandbox covers shell commands only: Claude's file tools, MCP servers and hooks run outside it. A project-level starting point from the docs:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

Put this in the project's .claude/settings.json, since . resolves to the project root there.

5. Write permission rules instead of relying on approval prompts

Codex combines a sandbox mode with an approval policy, and its experimental .rules files control which commands may run outside the sandbox (Codex rules). Claude Code's equivalent is allow, ask and deny rules, managed with /permissions and stored in settings files (permissions docs).

Three things to know before you write any:

• Order is fixed. Rules are evaluated deny, then ask, then allow. A broad deny like Bash(aws *) beats a narrower allow like Bash(aws s3 ls); specificity doesn't win.
• "Don't ask again" writes a file. Choosing it for a Bash command saves the rule to .claude/settings.local.json at the repo root, and it applies to future sessions in that repository.
• Scopes stack. ~/.claude/settings.json is you everywhere, .claude/settings.json is the team (commit it), .claude/settings.local.json is you in this project (settings docs). A deny at any level blocks an allow at any other.

Project allow rules only apply after you accept the workspace trust dialog, which is similar in spirit to Codex skipping project .codex/ layers in untrusted projects.

6. Use plan mode, and learn what /rewind can't undo

Both tools have a /plan command. In Codex it switches the chat into plan mode (Codex slash commands). In Claude Code, /plan does the same, and Shift+Tab cycles through permission modes, including plan, without typing anything (interactive mode). In plan mode Claude reads files and proposes a plan but makes no edits until you approve (common workflows).

Claude Code also checkpoints file edits before each prompt, and /rewind (or Esc twice on an empty prompt) can restore code, conversation or both (checkpointing docs). The limits matter: files changed only by Bash commands aren't tracked, most subagent edits aren't restored, and the docs are explicit that checkpoints don't replace version control. Keep committing as you would with Codex.

7. Move "always do this" rules into hooks

Instructions in CLAUDE.md or AGENTS.md are context, not enforcement. The memory docs say so directly: to block an action regardless of what Claude decides, use a PreToolUse hook. The same goes for anything that must happen every time, like formatting.

The hooks guide shows a PostToolUse hook that runs Prettier on every file Claude edits, in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

The same guide shows a PreToolUse script that exits with code 2 to block edits to files like .env, and Claude gets the script's message as feedback. Codex has hooks too, configured in hooks.json or [hooks] tables in config.toml, and it requires you to review and trust non-managed hooks before they run (Codex hooks). Event names such as PreToolUse and PostToolUse exist in both, but the config files differ, so port them by hand and check each one in /hooks.

Day-one checklist

1. Run /import codex --dry-run and read what it would bring over.
2. Confirm which instruction files load; use @AGENTS.md or the Project instructions setting.
3. Re-add MCP servers with an explicit scope; commit .mcp.json only for shared, credential-free servers.
4. Turn on /sandbox and add denyRead rules for secrets.
5. Write deny and ask rules first, allow rules second.
6. Plan big changes in plan mode; commit before you rely on /rewind.
7. Turn every "always" instruction into a hook.

Where to go next

If you want the basics on a few pages next to your terminal, the free Claude Code Quick-Start Cheat Sheet covers setup (Node check, install, API key, launch and the three spots where people commonly get stuck), the essential commands and five starter prompts, a task-by-task decision guide for Cursor vs Claude Code, and a 5-part instruction template, in 5 pages.

When you're ready to go deeper, Claude Code: The Complete Guide spends 45 pages and 22 chapters on installation for macOS, Linux and Windows via WSL2, three annotated sessions (a multi-file refactor, an intermittent-bug investigation and a full feature build), cost management, a CLAUDE.md deep dive with a template, headless mode with git hooks and CI, and a 30-day action plan.

This article was written with the assistance of AI and reviewed by the author.