从 Codex 转用 Claude Code 的配置要点

dev.to · AI#Claude Code#Codex#配置迁移

Editor brief · 编辑速览

文章聚焦两款编程工具的配置差异，帮助迁移用户避免沿用旧习惯导致配置失效。文中介绍通过 /import 迁移指令、MCP、命令、子代理和技能，并建议先用 --dry-run 预览迁移内容。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

从 Codex 切到 Claude Code，最容易出问题的地方，可能不是模型写错代码，而是你以为仍在生效的项目规则、权限和隔离措施，已经换了一套默认值。原文围绕迁移第一天列出七项配置，核心结论是：配置文件迁过去，不代表原来的行为也跟着迁过去。

它值得读的原因也在这里：不争论谁更会编程，而是检查工具到底读取哪些指令、能访问什么、哪些操作可以撤销。对同时使用两套工具的前端和全栈开发者，这些差异比一份模型排行榜更直接。

文件迁过去了，规则为什么可能没生效

先别急着手动重建配置。原文介绍，Claude Code 的 /import 可以从本机的 OpenAI Codex、Google Gemini CLI 或 Cursor 导入指令文件、MCP servers、命令、subagents 和 skills。执行 /import codex --dry-run，可以先查看导入清单，不写入文件；/init 发现 Codex 或 Gemini CLI 配置时，也会提供导入选项。

但清单只能证明文件会被搬过来，不能证明运行方式相同。

以项目指令为例，Codex 会先读取 ~/.codex 下的全局指令，再从项目根目录沿路径读到当前目录，每个目录最多取一个文件，优先检查 AGENTS.override.md，然后才是 AGENTS.md。

按照原文引用的文档，Claude Code 从 v2.1.277 起也支持 AGENTS.md，但默认有个条件：工作目录及其上层不能存在 CLAUDE.md、.claude/CLAUDE.md 或 CLAUDE.local.md。加一份个人备注文件，都可能让共享的 AGENTS.md 停止加载。它也不读取 AGENTS.override.md。

可选办法有两个：在 /config 中把 Project instructions 设为 claude-md-and-agents-md，让两类文件共同加载；或者在 CLAUDE.md 中用 @AGENTS.md 引入共享规则，再补充 Claude Code 专用要求。原文称，保留这种引用不会导致重复读取，也适用于没有原生 AGENTS.md 支持的会话。会话内可以用 /memory 打开和编辑相关文件。

MCP 同样需要检查配置位置。Codex 使用 ~/.codex/config.toml，或受信任项目中的 .codex/config.toml，以 [mcp_servers.<name>] 配置服务；Claude Code 不读取这些文件。

Claude Code 的添加命令是 claude mcp add --transport stdio my-server -- npx -y some-mcp-server。其中 -- 分隔 Claude Code 参数与服务启动命令，更容易漏掉的是作用域：

local 是默认值，只供本人在当前项目使用，存于 ~/.claude.json。
project 写入仓库根目录的 .mcp.json，适合团队共享，需要显式传入 --scope project。
user 对本人所有项目生效。

.mcp.json 中的服务还要经过交互式批准才会连接，此前 claude mcp list 会显示 pending。涉及凭据的配置应留在 local 或 user，避免把秘密提交到仓库。

沙箱和审批，分别管住什么

原文强调的最大差异是默认隔离：按其引用的文档，Codex CLI 和 IDE extension 默认让模型生成的命令运行在操作系统沙箱中，禁止网络访问，写入限制在活动工作区；Claude Code 的 shell 沙箱默认关闭，需要通过 /sandbox 开启。

Linux 和 WSL2 需要 bubblewrap、socat，缺少时面板会提示；原生 Windows 的命令则不受这套沙箱隔离。

开启也不等于已经保护好秘密文件。原文指出，沙箱内的命令默认仍能读取机器上的大部分文件，包括 ~/.ssh 和 ~/.aws/credentials，需要额外配置 denyRead。

下面是原文给出的项目级读取限制起点，放在 .claude/settings.json：

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

重点看 allowRead 的 "."：在这个项目配置文件中，它解析为项目根目录。这只是起点，不能据此推断全部工具都被隔离，因为沙箱只覆盖 shell 命令，文件工具、MCP servers 和 hooks 在它之外运行。

沙箱限制命令能触碰哪里，权限规则决定哪些工具操作可以执行。

Codex 把 sandbox mode 与 approval policy 组合使用，实验性的 .rules 控制哪些命令可以在沙箱外执行。Claude Code 则通过 /permissions 管理 allow、ask、deny，并存进 settings 文件。

这里不能套用「越具体越优先」的直觉。规则固定按 deny、ask、allow 顺序判断，Bash(aws *) 的拒绝规则会压过 Bash(aws s3 ls) 的允许规则。

配置还会叠加：~/.claude/settings.json 管个人全局，.claude/settings.json 管团队项目，.claude/settings.local.json 管个人在当前项目的设置。任意层级的 deny 都能阻止其他层级的 allow。选择 Bash 审批里的「Don't ask again」，也会把规则写入项目的 .claude/settings.local.json，影响后续会话。

项目 allow 规则要在接受工作区信任对话框后才生效。迁移时应先明确拒绝和询问的边界，再逐项放行常用操作。

「每次都做」要靠执行机制，撤销也有边界

CLAUDE.md 和 AGENTS.md 提供的是上下文。即使写上「始终格式化」「禁止修改 .env」，也不等于建立了执行门禁。

原文建议，需要拦截动作时使用 PreToolUse hook；需要每次编辑后运行的任务，则使用 PostToolUse。下面的原样配置会在 Claude 通过编辑工具修改文件后运行 Prettier，同样放入 .claude/settings.json：

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

要看清 matcher 的 Edit|Write：它匹配的是这两个工具事件，不能据此认定 Bash 写入的文件也会被格式化。示例还依赖 jq、npx 和可用的 Prettier 环境，复制配置并不等于验证完成。

原文另举了 PreToolUse 脚本以退出码 2 阻止编辑 .env 的办法，脚本消息会反馈给 Claude。Codex 也有 hooks，配置在 hooks.json 或 config.toml 的 [hooks] 中，非托管 hooks 运行前需要审查和信任。两边虽然都有 PreToolUse、PostToolUse，配置仍需逐项移植，再到 /hooks 检查。

大改动则先用计划模式。两套工具都有 /plan，Claude Code 还可用 Shift+Tab 切换权限模式；计划模式允许读取文件、提出方案，批准前不做编辑。

至于 /rewind，它可以恢复代码、对话或两者，也能在空输入框连按两次 Esc 触发。Claude Code 会在每次提示前为文件编辑建立检查点，但 Bash 单独修改的文件不受跟踪，大多数 subagent 编辑也不能恢复。

检查点不能替代 Git，尤其不能替你撤销所有命令副作用。

我的判断

原文最有价值的地方，是把迁移问题拆成了可检查的配置差异：指令加载、共享作用域、沙箱、权限和 hooks，各自解决不同问题。相比把所有要求塞进一份超长指令文件，这种分工更容易定位「为什么规则没生效」。

但它是一份文档整理，不是迁移实验报告。作者称七项内容来自双方官方文档，没有给出完整测试环境、失败率或迁移前后的对照数据。文中截至 10 月 25 日的一周 X 帖子统计，Claude Code 为 69,609 条，Codex 为 20,893 条，超过三比一；原文没交代检索口径，不能拿它证明用户规模或工具质量。

「每个 always 都改成 hook」也应有取舍。格式化、明确的文件拦截适合自动执行；架构判断、需求理解仍需要上下文。对于团队格式规范，hook 可以缩短反馈时间，CI 仍适合承担最终校验，两者覆盖范围不同。

同样，denyRead: ["~/"] 可能影响依赖主目录配置的开发命令。团队需要按实际需求验证读取范围。原文给的是配置起点，没有证明它适合所有仓库。

能拿来做什么

在现有前端或 Node 仓库先运行 /import codex --dry-run，对照检查指令、MCP 和 hooks 的去向，并确认当前版本实际加载了哪份规则。
团队同时使用两套工具时，可以集中维护 AGENTS.md，通过明确的加载设置或 @AGENTS.md 引用复用，避免共享规范因个人配置而失效。
把 Prettier 这类确定性操作接入 hook 后，实际触发一次 Edit 或 Write，检查命令能否成功执行；再分别验证 shell、文件工具和 MCP 的权限边界。
多文件重构前使用 /plan，开始修改前提交 Git。涉及 Bash 写文件或 subagent 协作时，按原文列出的限制评估 /rewind 能恢复什么。