Codex怎么分叉旧会话？fork、resume与工作目录核对

已经与Codex讨论过一套方案，想另开思路又不想重新解释背景，可以分叉会话。fork创建新聊天，resume继续原会话；两者都不自动代表仓库文件已经隔离。本文先做只读方案比较，不直接让两个会话同时改同一文件。

第一步：确认要保留的原会话

先记录原会话主题、项目目录和最后确认的约束，确保没有把未完成的建议当成已实施结果。文件状态还应独立查看：会话里说“准备修改”不等于工作树已经改变。

确定新分支要探索什么，例如沿用相同接口但比较另一实现方案。不要为了一个小问题复制所有会话，临时回顾与正式另开任务各有用途。原会话和分叉都可能继续存在，应给出可辨认名称。

第二步：通过选择器分叉

在CLI中运行codex fork打开旧会话选择器，明确选目标会话。–last默认取当前工作目录最近会话，–last –all扩大到所有目录；在多项目环境先用选择器更容易确认，不凭最近时间推断归属。

codex fork

# 已确认当前目录最近会话确为目标时：
codex fork --last

第三步：处理工作目录选择

当前目录与保存目录不同，官方说明fork会沿用resume的目录提示和tui.resume_cwd设置。进入新聊天后先报告实际工作目录与仓库身份，再读取文件，不能只看继承的聊天内容判断位置正确。

新会话继承讨论上下文，不会冻结外部文件。原会话之后修改文件，新会话读取到的可能是新状态。必要时重新比较当前文件与继承的假设，把过期结论标出来。

这是方案B的只读探索。先确认当前目录与已有文件状态，再复述从原会话继承的约束。只比较方案，不修改文件、不运行有副作用命令、不提交或推送。

第四步：区分聊天分叉与Git隔离

fork创建新聊天，不等于git branch或worktree。若两边要独立改代码，应先设计文件隔离并确认分支，不让两个会话在同一工作树交错写入。已有worktree教程处理的是这个文件层问题。

resume则继续同一聊天，适合单一路线延续。选择错误时先停止新的修改，回到正确目标；不要用删除文件来“撤销聊天分叉”。会话管理和Git恢复是两套操作。

第五步：比较方案后再实施

两边结果都按目标、约束、改动范围、风险、验证计划比较，不仅比较语言流畅程度。记录哪份结论来自原会话、哪份来自分叉，重要事实回到当前文件确认，避免用旧上下文自我印证。

验收：原会话仍可识别；新聊天身份清楚；工作目录正确；继承约束已核对；无意外写入；两方案有相同评价维度；选定实施路线后只在明确环境执行。

第六步：避免重复执行

如果分叉用于重试失败任务，先检查旧会话是否已经完成某些操作。新聊天不会自动撤销外部动作或保证幂等，不能因它“从之前开始”就重新执行所有部署、发信或提交步骤。先核对实际状态，再决定下一步。

官方资料

资料核对日期：2026年11月14日。

• OpenAI：Developer commands