任务又复杂又说不清，或要做迁移和多步改动时，先强制开 /plan，看完方案再允许改代码。小而清楚的单点修改不必开。这是工作流建议；Plan mode 不会从机制上禁止改文件。
要点
- 官方现用名称是 Plan mode。ChatGPT 桌面应用、Codex IDE 扩展和 Codex CLI 都用斜杠命令
/plan。官方最佳实践写：任务复杂、含糊，或不好一次说清时，先让 Codex 做计划再开始写代码；跳过多步任务的 planning，被列成常见错误。（Best practices） - 教学默认走
/plan。官方文档仍写可用/plan或 Shift+Tab 切换；2026 年 7 月起有用户报告，桌面应用和 VS Code 扩展里 Shift+Tab 不再切换，/plan仍可用。快捷键以你当前客户端为准，不要把它写成现在必定能用。（Issue #32147） - CLI 可以写成
/plan Propose a migration plan for this service。Codex 正在工作时，这条命令暂时不可用。（CLI slash commands） /goal是 Goal mode，和 Plan mode 分开用。官方顺序是先/plan再/goal。开启 goal 不会扩大权限，仍使用原来的 sandbox 和 approval policy。（Slash commands、Long-running work）- 审批和沙箱是另一组旋钮：Ask for approval，还有 Approve for me 和 Full access；配置值为
on-request或never，sandbox 则是read-only、workspace-write或danger-full-access。官方现页没有写“Plan mode 会从机制上禁止改文件”。需要硬只读，走 sandbox 或/permissions里的 Read Only。不要把 Claude Code 的 plan permission mode，或 Cursor 自带的 Plan Mode，当成 Codex 的按钮。（Sandboxing、Permission modes、Cursor Plan Mode、Claude Code permission modes） - 失败回合怎么 rewind，陌生仓库的只读探索，还有 monorepo 里如何声明工作区边界，以及贴 CI 日志时怎么限制改动范围，站内已有专文。本篇只谈何时先 Plan 再改代码。（Codex：失败回合怎么 rewind／缩小范围再开、Codex：只读探索陌生仓库的提问顺序、Codex：打开 monorepo 时，先声明哪些包在范围内、Codex：把失败的 CI 日志贴进去时，怎么限制改动范围）
正文
场景
一次服务迁移，或需求还只是“先把认证改到新方案”。你把任务丢进 Codex，它直接开始改文件。二十几个文件之后，你才看清它选的兼容策略根本不对。回退的成本，已经比先问一句方案要高。
官方最佳实践把这类情况写得很直：任务复杂、含糊，或不好一次说清，就先让它 plan，再开始写代码。Plan mode 会收集上下文、提出澄清问题，并在实现前给出更稳的计划。多步任务如果跳过 planning，被单独列成常见错误。迁移用例还要求先盘点改动面，再给出带检查点的计划，不要一次重写。
这是时机判断的示意，不是某次逐字实测。下面说的“强制打开”，是工作流建议。官方产品里没有强制开关，也没有写 Plan mode 必须常开。
可跟做步骤／可抄工作流
先确认你按的是哪一个产品的 Plan
Codex 的入口一致：在 ChatGPT 桌面应用、Codex IDE 扩展或 Codex CLI 的输入框里键入 /plan。提示词指南的说法是：多步任务里，想先调查并提出 approach、再编辑时，就进 /plan。
Cursor 自带的 Plan Mode 是 Cursor Agent 的模式，官方还写：快改或做过很多次的任务，直接走 Agent mode 即可。Claude Code 的 plan 是一种 permission mode，文档写明规划期间不改源文件，编辑会一直挡住，直到你批准计划。这三个产品都可能用到 Shift+Tab，最容易按错。Cursor 里如果同时装着 Codex 扩展，会有两套入口，不要混成一个按钮。本篇下面的步骤只针对 Codex 的 /plan。
这类任务先强制开 Plan mode
下面这些情况，官方建议先 plan，工作流上可以强制先打开。
- 任务复杂、含糊，或不好一次说清（官方最佳实践）
- 多步工作（官方把跳过 planning 列为常见错误；提示词指南也针对 multi-step task）
- 迁移或现代化：先盘点，再给带检查点的计划，不要一次重写（官方 code-migrations）
- 长任务的目标还不清楚：先
/plan，让它提问并收成可验证的目标，需要长期推进时再/goal（官方 long-running work）
用法建议（官方现页没有这句原话）：单文件或规格已经写得很清楚的改动，以及正在快速试错的小修复，不必先开 Plan mode。官方触发词是复杂或含糊，以及多步；不要把“强制”当成所有任务的默认值。
打开时以 /plan 为默认教学。CLI 还可以把规划请求写在同一行，例如：
/plan Propose a migration plan for this service. Ask clarifying questions before listing checkpoints. Do not start editing files in this turn.文档仍写可以用 Shift+Tab 切换。2026 年 7 月，issue #32147 的作者报告：更新后“Shift+Tab no longer toggles Plan Mode”，“The /plan command still works”。有评论称，桌面应用合并后也拿掉了该快捷键。以你当前客户端为准；斜杠命令更稳。CLI 里，Codex 正在工作时 /plan 暂时不可用，等这轮结束后再切。
看完方案，再允许它改代码
官方对 Plan mode 的保证，是它会先做计划和提问。现页没有写下类似 Claude Code 的句子：规划期间从机制上禁止改源文件。不要假设打开 /plan 就已经锁死写入。
高风险、必须先看方案再动文件时，用法建议叠加官方只读约束：
codex --sandbox read-only --ask-for-approval on-request或在 CLI /permissions 里选文档所称的 Read Only。方案确认之后，再放宽到 workspace-write，或桌面／IDE 权限菜单里的 Ask for approval。这是权限步骤，和 Plan mode 分开调。旗标全称是 --ask-for-approval，不要写成 --ask。已退役的 approval_policy = "untrusted" 不要拿来当“更安全的规划模式”，帮助中心写明它会导致无法启动。
看计划时至少核对：要改哪些路径，分几步，每一步怎么验证，哪些地方还没问清楚。方案还在飘，就不要批准它开始改。
需要跨很多轮自己推进时，再用 /goal。官方顺序是先 /plan 再 /goal。开启 goal 不会扩大 sandbox 或 approval policy。Goal mode 点到这里即可，不必另开一套教程。
PLANS.md 或 ExecPlan 是可选的文档约定，用来跨会话、跨小时记下执行计划。官方称它为高级、可选；相关 cookbook 已 archived，只能当写法参考。不要把它写成 /plan 按钮，也不要和 Plan mode 写成同一件事。
配置里还有可选键 plan_mode_reasoning_effort，允许给 Plan mode 单独覆盖推理力度，官方样例值为 high。未设置就用内置预设。不要把它当成打开 Plan mode 的前提。
实施后如果还停在规划里
有用户报告：按实施计划之后，模型把计划又输出一遍，并卡在 Plan mode 里，只能新开对话。这类按钮名没有出现在本次打开的官方文档里，具体叫什么以现页为准。官方没有把这一步写成排障页。可以再用一次 /plan 切一下，或开一条新聊天继续执行。
真实用户诀窍／反例
- 诀窍：复杂或含糊，以及多步或迁移，先
/plan。 官方把“跳过多步任务的 planning”写成常见错误。强制用在这类任务上，不要当成全局默认。 - 诀窍：教学入口用
/plan。 快捷键以当前客户端为准。文档仍写 Shift+Tab，但有用户报告部分客户端已拿掉。 - 诀窍：看完计划再放写权限。 Plan mode 负责先规划；硬只读要靠 sandbox 或 Read Only。
- 诀窍：目标清楚、改动面很小，就不必开。 单点修改先 plan，常常只是多一轮复述。这是用法建议，官方现页没有这句原话。
- 反例：把 Cursor Plan Mode 或 Claude Code 的 plan permission mode 当成 Codex 的 Plan 按钮。 三者都可能碰到 Shift+Tab，按错很常见。
- 反例：把 Ask for approval 或 Read Only，以及
--sandbox read-only叫成 Plan mode。 官方写明 sandbox 与 approval 是另一组控制；ChatGPT 网页甚至没有本地 sandbox 或 approval 选择器。 - 反例：用
/goal代替第一轮规划。 官方明确先 plan 再 goal。 - 反例：声称打开 Plan mode 就一定不会改代码。 官方现页没有这句保证。Claude Code 才把“不改源文件直到批准”写进权限模式。
- 反例：所有小改动都强制 Plan mode。 官方触发词是复杂或含糊，以及多步。
- 反例：把失败后 rewind、只读逛陌生仓库，或 monorepo 工作区边界，重写成这篇的 Plan 教程。 只读探索应指向官方 read-only sandbox，那篇已单独写过。
适用边界
- 这篇覆盖：在 ChatGPT 桌面应用、Codex IDE 扩展或 Codex CLI 里，判断何时先开 Plan mode，再允许改代码。“强制”是工作流建议。不保证某一版本的快捷键或菜单文案长期不变，以你当前客户端现页为准。
- 不覆盖：失败回合 rewind，只读探索陌生仓库的提问顺序，monorepo 工作区边界，以及贴 CI 日志时限制改动范围。那些题目站内已有专文。
- Plan mode 的套餐门槛，以及是否默认打开、Free 或 Go 是否完整提供
/plan，已打开的定价和帮助中心页没有写，这里不写死。Codex 随 ChatGPT 计划提供，用量因计划而异。 - 功能概览页的示意图里出现过 “Plan mode / Turn plan mode on”，未登录应用现页，不写死它在客户端里的精确位置。社区里出现过的实施计划类按钮，同样以现页为准。
- 打开 Plan mode 不等于已经锁死写入。高风险改动请叠加只读沙箱，并在放行后自己看 diff。生产仓库的权限、密钥和合并，仍走独立审批。