先说结论：它们是两种默认姿势
两边的目标一致：让模型在你的仓库里自主完成一段工程任务。差别在默认值。Codex 的默认重心是“本地 + 云端两条腿”：本地在 CLI、IDE、桌面端里跑，云端在已发布的环境里跑长任务，额度和 ChatGPT 订阅共用一套。Claude Code 的默认重心是“终端为中心，规则与扩展围绕终端长出来”：CLAUDE.md、skills、hooks、subagents、Agent SDK 都在同一套体系里。
- 如果你的团队习惯“给目标 → 等结果 → 收 PR”，Codex 的云端任务和 GitHub 集成更顺手
- 如果你习惯“守在终端里逐步推进 + 用 hooks 把格式化、lint 卡死”，Claude Code 的默认面更贴合
- 两边都可以只用 CLI，也都可以接 API Key 按量计费，所以这不是“能不能”的问题，是“顺不顺手”的问题
入口形态：你打算在哪儿用它
两边的 surface 都很多，但重心不同。下面这张表只列官方文档明确写了的入口，具体可用性以官方页面为准。
| 入口 | Codex | Claude Code |
|---|---|---|
| 终端 CLI | 有（Codex CLI） | 有（终端 CLI 是主力形态） |
| IDE 扩展 | 有（IDE extension） | 有（VS Code、JetBrains） |
| 桌面 App | 有（ChatGPT 桌面端的 Codex 视图） | 有（独立桌面 App） |
| 云端任务 | 有（Codex Cloud，需要已发布的环境） | 有（网页版与移动端） |
| CI / 代码审查 | Codex GitHub Action、PR 审查 | GitHub Actions、GitLab CI/CD、GitHub Code Review |
| 嵌入式集成 | app-server 协议、Codex SDK | Agent SDK |
一个实际差别：Codex 的云端任务是“先建环境再跑”，环境里装什么、能连哪些服务都要提前配好，好处是同一套环境可以复用到很多任务；Claude Code 的网页版更接近“直接把任务丢上去”，配置负担小，但环境定制度也低一些。
模型与额度：钱到底怎么算
这是最容易被写成一团模糊的地方。两边的共同点是：订阅制下用的是“额度池”，不是按 token 实时扣钱；接 API Key 时才是按 API 价格计费。具体档位和价格一定以官方页面为准，这里只说结构。
| 维度 | Codex | Claude Code |
|---|---|---|
| 订阅来源 | ChatGPT 个人/团队/企业档位；Codex 与 ChatGPT Work 共用同一套额度 | Claude 的 Pro / Max / Team / Enterprise 档位 |
| 额度查看 | 网页端用量页，CLI 里用 /status | 会话里用 /usage，可看额度条与本次会话 token |
| 超额怎么办 | 可购买额度继续跑；也可换 API Key 跑本地 | 可加购 usage credits；也可用 Console 的 API Key |
| 按量计费 | API Key 按 API 价格，无云端功能 | Console API 按 API 价格，受速率限制 |
| 多花钱换速度 | 有速度档位，倍率更高 | 可换更强的模型档位 |
规则文件：CLAUDE.md 和 AGENTS.md 怎么放
两边的规则体系思路一致：分层、就近覆盖、按需加载。区别在文件名和几处细节。Codex 读 AGENTS.md，Claude Code 读 CLAUDE.md；而且 Claude Code 现在也能直接读 AGENTS.md（默认行为是：仓库里有 CLAUDE.md 就用 CLAUDE.md，没有才用 AGENTS.md），所以“一份规则喂两个工具”是可行的。
| 细节 | Codex（AGENTS.md） | Claude Code（CLAUDE.md） |
|---|---|---|
| 全局规则 | ~/.codex/AGENTS.md | ~/.claude/CLAUDE.md |
| 项目规则 | 仓库根 AGENTS.md，向下逐层叠加 | ./CLAUDE.md 或 ./.claude/CLAUDE.md |
| 覆盖文件 | 同目录下 AGENTS.override.md 优先 | CLAUDE.local.md，加载在同级 CLAUDE.md 之后 |
| 合并顺序 | 从仓库根合并到当前目录，越近越靠后 | 从文件系统根合并到当前目录，越近越靠后 |
| 容量上限 | 合并后默认上限 32 KiB | 单文件建议 200 行以内，超大文件会被跳过 |
| 细分规则 | 嵌套目录各自放 AGENTS.md | 点目录 .claude/rules/，可用 paths 只对匹配文件生效 |
| 引用其他文件 | 支持回退文件名配置 | @path 导入，最多四层 |
# 方案一：CLAUDE.md 里只写一行导入
echo '@AGENTS.md' > CLAUDE.md
# 方案二：符号链接（注意 Edit/Write 工具不写穿符号链接）
ln -s AGENTS.md CLAUDE.md
# 验证 Claude Code 到底加载了哪些记忆文件
# 会话里执行：/context，看 Memory files 一栏审批与沙箱：默认有多严
这是两边哲学差异最大的一节。Codex 把沙箱和审批拆成两层：sandbox 决定“技术上能做到什么”，approval policy 决定“什么时候必须问你”。Claude Code 把审批做成权限模式，沙箱是一个可以自己打开的开关。
| 层面 | Codex | Claude Code |
|---|---|---|
| 沙箱默认状态 | 本地默认开着：workspace-write，写权限限工作区，默认无网络 | Bash 沙箱默认关闭，需要在会话里跑 /sandbox 或改配置打开 |
| 沙箱实现 | 操作系统层面的机制（macOS / Linux） | macOS Seatbelt、Linux/WSL2 的 bubblewrap 加 socat |
| 只读模式 | sandbox_mode 设为 read-only，配合 /permissions 切换 | 权限模式里的 plan 模式：先分析再动手 |
| 审批粒度 | approval_policy 可取 on-request 或 never，也可配成更细的 granular | default / acceptEdits / plan / auto / dontAsk / bypassPermissions |
| 网络放行 | 在配置里显式打开 network_access，或按域名放行 | 沙箱默认无直连，走本机代理并按 allowedDomains 逐个放行 |
| 全放开 | --dangerously-bypass-approvals-and-sandbox（别名 --yolo），官方明确不推荐 | bypassPermissions 模式，文档同样标为跳过所有检查 |
| 企业管控 | MDM / 托管配置可压过本地设置 | managed settings 可下发权限 deny 规则与沙箱强制 |
# Codex：工作区可写 + 需要时才问
codex --sandbox workspace-write --ask-for-approval on-request
# Codex：只读 + 绝不打扰，适合 CI 里的只读巡检
codex exec --sandbox read-only --ask-for-approval never
# Claude Code：先规划不动手
claude --permission-mode plan
# Claude Code：无头模式下把可用的工具限定死
claude -p "review the diff and list risks" --allowedTools "Read,Grep"并行与 CI：谁能同时干几件事
并行这件事，两边都靠 git worktree 落地，但包装方式不同。Codex 把它做成新会话时的三选一环境：Local 直接改当前目录、Worktree 用 worktree 隔离、Cloud 在云端环境里跑；Worktree 默认是 detached HEAD，改动可以用 Handoff 搬回 Local。Claude Code 把它做成命令行开关：加 -w 直接进 worktree，配合 tmux 可以一屏看多个会话。
| 能力 | Codex | Claude Code |
|---|---|---|
| 本机并行 | 新建会话时选 Worktree，每个会话独占一份检出 | claude -w 名称，落在仓库的 .claude/worktrees 下 |
| 多会话视图 | 桌面端侧栏按聊天管理，每个聊天绑定自己的 worktree | 配合 tmux 或多开终端；另有后台会话视图 |
| 云端执行 | Cloud 环境，任务各自独立工作区，可配网络与凭据 | 网页版/移动端跑云端会话，可从终端把本地会话带上去 |
| 会话搬移 | Handoff 在 Local 与 Worktree、本机与远程主机之间搬对话和 Git 状态 | 会话可在终端、桌面、网页之间接手 |
| CI | Codex GitHub Action 跑 codex exec；PR 审查可直接在 GitHub 上触发 | GitHub Actions、GitLab CI/CD 跑 claude -p；GitHub Code Review 可对每个 PR 自动审 |
| 成本口径 | 云端任务更费额度；GitHub 上的 Code Review 单独计额度 | 本地 /review 走普通额度，云端会话按订阅额度计 |
什么场景选哪个，以及怎么并存
| 你的情况 | 建议 | 理由 |
|---|---|---|
| 已经在用 ChatGPT 订阅，主要写业务代码 | 先用 Codex | 额度和订阅共用，本地与云端同一入口，边际成本最低 |
| 团队重度依赖 hooks 卡质量门禁 | 先用 Claude Code | hooks、skills、rules 这套扩展面在终端里更成体系 |
| 大量“丢给云端跑、收 PR”的任务 | Codex 更顺 | Cloud 环境可预配置依赖与凭据，任务间可复用 |
| 需要把智能体嵌进自己的产品 | 看 app-server / Agent SDK 哪个更贴合 | 两者都能嵌，接口形态不同 |
| 只是偶尔改几行、不想多花钱 | 任选本地 CLI，别用云端 | 云端任务额度和时长成本都更高 |
| 合规要求严、必须统一管控 | 两边都要配托管设置 | 审批和沙箱都能被企业策略压住，别指望默认值 |
- 01
1. 把规则收敛成一份
用 AGENTS.md 作为唯一事实来源，需要时在 CLAUDE.md 里导入它。规则内容只写“这个仓库特有的约定”，别把通用编程常识抄进去。
- 02
2. 迁移历史配置
Codex CLI 里有 /import，可以从 Claude Code 导入指令文件、settings.json、skills、plugins、记忆、MCP 配置、hooks、slash 命令和 subagents；导入后逐项复核权限和 MCP 认证。
- 03
3. 定好各自的职责边界
常见分工：一个工具做日常小改动和交互式探索，另一个做长任务和 PR 审查。别让两个智能体同时改同一个工作区。
- 04
4. 用同一批任务验收
同一批输入分别跑一遍，记录需要你纠正的次数和实际消耗，过一段时间再复评。工具在变，结论也会变。
常见问题
两个都装会冲突吗？
不冲突，它们各自读写自己的配置目录（Codex 默认 ~/.codex，Claude Code 默认 ~/.claude），也不共享会话历史。唯一要小心的是同时在同一份工作区里跑，两边都会改同一个文件树，容易互相踩到未提交的改动，建议用 worktree 隔开。
规则文件要不要维护两份？
不需要。把仓库特有约定写在 AGENTS.md，Claude Code 能直接读它，或者在 CLAUDE.md 里加一行 @AGENTS.md 导入。真正需要分叉的只有“工具特有的配置”，比如 hooks 定义、skill 目录、权限规则，这些本来就该各写各的。
哪边更省钱？
取决于你怎么用，而不是哪边定价更低。订阅制下两边都是额度池，省额度的通用做法一致：缩小上下文、只给相关文件、限定输出、少挂 MCP server、能在本地跑就别用云端。具体额度和价格以官方页面为准。
能不能只在 CI 里用一个？
可以。Codex 侧用 Codex GitHub Action 跑 codex exec，Claude Code 侧用 GitHub Actions 或 GitLab CI 跑 claude -p，都能在只读沙箱里做审查。CI 里务必用最小权限，并给非交互运行设好沙箱与审批策略，别让它默认放开写权限。
官方文档与参考
本文依据上述官方文档整理；价格、额度与功能会随官方更新变化，第三方中转站的行为以其自身说明为准。