怎样把 Claude Code 的工作安全接到 Codex？

适用边界与版本日期

这套流程适合已经在 Claude Code 中积累项目规则或工作习惯，希望让 Codex 接手同一项目的人。本文按 2026-08-30 的公开实践整理。产品界面和可导入范围可能变化，因此本文不把某个菜单名称、数量限制或兼容范围写成永久事实。

“接到 Codex”不是删除 Claude Code 配置，也不是把所有账号和插件复制过去。目标是保留原环境、明确迁移清单、验证 Codex 实际读到了什么，并为未迁移项安排替代方式。

跟着做

如果你还没有可导入环境，或暂时不想触碰真实配置，先用空白核对表虚构三项规则与一项工具，只演练下面第 1—3 步。能正确分类并写出恢复点后，再决定是否进入真实导入。

1. 先盘点现状。 在核对表中分别列出：项目规则文件、个人规则、常用命令、插件或工具、环境变量来源、外部账号、自动化动作。敏感值只记录“存在 / 不存在”，不要复制值。
2. 保存可恢复基线。 记录项目当前版本和工作区状态，备份需要迁移的配置文件。不要为了导入而删除或覆盖原配置。
3. 划分迁移类型。 把每项标成“文本规则”“本地工具”“外部身份”“自动化”。文本规则可能被读取；工具需要在 Codex 环境验证；账号通常需要单独登录；自动化需要重新确认触发与权限。
4. 使用当前可见的官方导入入口。 只选择盘点表中的来源。若界面要求扩大目录权限、登录新账号或接受额外条款，先停在确认前，判断是否属于本次授权。
5. 逐项做导入后核对。 让 Codex说明它看见了哪些规则，再用文件或设置页面核对。对“未出现”“语义变化”“需要另配”分别记录，不用一句“导入成功”覆盖差异。
6. 跑一个低风险接力任务。 选择现有项目中可回滚、无外发、无凭据的真实小任务。先要求 Codex复述规则和修改边界，再执行、测试并查看差异。

完成接力任务后再问：Codex 遵守了哪三条迁移规则？哪些能力实际上没有迁移？如果回到 Claude Code，原环境是否仍可使用？

应该看到什么

你应得到一张逐项状态表，而不是一个笼统的“迁移完成”：文本规则有读取证据，本地命令有运行结果，外部身份标明是否重新授权，自动化标明是否仍处于关闭状态。

低风险任务应留下清晰的计划、有限差异和相关测试结果。原 Claude Code 配置仍在，项目没有因导入产生无关改动；任何未兼容能力都被显式列为待办，而不是默默假设可用。

证据与验收

至少保留以下证据：

• 导入前的配置清单与可恢复版本；
• 导入后 Codex 实际可见规则的逐项对照；
• 工具、插件、身份和自动化的独立状态，不互相替代；
• 低风险接力任务的真实差异、测试和人工验收；
• 未迁移项的处理决定：另配、暂缓或弃用。

只有界面显示“成功”但没有上述对照，最多说明一次导入动作结束，不能说明工作流已经可靠接管。

常见失败、补救与停止线

• 把规则、插件和账号当成同一种东西： 回到四类盘点，分别验证，不用文本导入代替工具或身份配置。
• 导入前覆盖原文件： 从基线恢复，改用副本或版本控制后重新操作。
• 一上来跑发布任务： 换成可回滚、无外发的小任务，先证明规则读取和执行边界。
• 把模型自述当作读取证据： 对照实际规则文件、设置状态和任务行为。

当导入要求显示或复制敏感值、准备覆盖现有配置、触发外部发送或部署、无法恢复原环境，或实际行为违反项目规则时，立即停止。先恢复基线，再决定是否继续迁移。

来源与深入阅读

本文给出迁移前后的快速核对路径。要查看一次真实导入中“入口可用”与“能力完整迁移”为什么必须分开判断，请阅读 《我把 Claude Code 的配置导入 Codex》。