别让Codex猜：这个开关先问再干

别让Codex猜：这个开关先问再干

Codex 做长任务时，我最担心的不是它不会，而是它太快开始做。

“把这批文件整理一下”，它可能直接按自己的理解改名；“把重复数据清掉”，它可能替你决定保留哪一条；“把这版部署一下”，它可能默认了环境、账号和目标分支。方向一旦猜错，后面的命令、修改和验收都会建立在错误前提上。

今天的素材里有一个很小、但很实用的配置：让 Codex 在需要你做决定时主动确认，即使不在 Plan mode，也别带着错误假设一路跑下去。

我没有把一条社区动态直接当成结论，而是在本机先验证了配置层。当前 Codex CLI 版本是 0.143.0；codex features list 能看到 default_mode_request_user_input，默认值是 false；用命令行临时覆盖后，它会变成 true。

01 这不是“多问一句”，而是给任务加闸门

很多人把 Agent 的体验理解成：越少打断越好。

我现在反而会把任务分成两类。目标、路径、范围和验收都明确时，让 Codex 连续执行；只要有一个关键选择会改变结果，就先停下来问。

最应该触发确认的通常有三种：一是目标不唯一，比如“整理”究竟是分类、改名还是删除；二是目标唯一但代价不同，比如覆盖旧文件还是新建副本；三是涉及外部状态，比如发消息、上传、部署、修改线上数据。

这类问题如果等到最后才暴露，返工成本很高。提前问一句，损失只是十几秒；猜错后再回滚，损失可能是一整段任务链。

我遇到过最典型的场景，是让 Codex 整理一批按日期命名的资料。看起来只是文件操作，实际藏着四个决定：日期取文件名还是正文时间；同一天有多份时怎么排序；缺日期的文件放哪里；整理完成后是移动原件还是只生成索引。任何一个没说清，最终目录都可能“整齐但不可用”。这正是应该停下来问的地方，因为答案不属于模型推理，而属于我的工作规则。

02 先临时验证，不要急着改全局配置

我会先跑三条命令：

codex --versioncodex features list | rg default_mode_request_user_inputcodex -c 'features.default_mode_request_user_input=true' features list \ | rg default_mode_request_user_input

第三条只对当前命令做临时覆盖，适合先确认本机版本是否识别这个开关。看到结果从 false 变成 true，只能说明配置被正确读取，还不能证明交互层一定会弹出问题。

确认无误后，再把下面两行加入 ~/.codex/config.toml：

[features]default_mode_request_user_input = true

如果文件里已经有 [features]，只补键值，不要再写一个重复分节。TOML 的重复表头可能让整个配置加载失败。

03 我会用一个故意含糊的任务做验收

开启之后，不要拿“读取这个文件并总结”来测试。这个任务本来就没有关键分叉，Codex 不提问反而是正常的。

更合适的测试是准备一个临时目录，放三份名字相近的文本，再说：

把这些重复内容清理一下，留下最终版本。

合格表现不是立刻删除，而是先确认至少一个关键选择：按文件名还是内容判重，保留最新修改时间还是信息最完整的一份，原文件是删除、移到备份目录，还是只生成清单。

然后再给一个边界完整的任务：

只扫描当前目录，不改文件；按内容哈希列出重复项，把报告写到 duplicates.md。

这次它应该直接执行，不需要为了“显得谨慎”反复打断。一个好用的确认机制，不是把 Agent 变成问答机，而是只在决定权真的属于你时把问题交回来。

04 三关都过，才算真正生效

我的验收会分三层。

配置层：功能名存在，临时覆盖后能从 false 变成 true。

交互层：故意含糊的任务会先出现选择或追问，而不是直接执行高影响动作。

边界层：目标已经写清楚时，Codex 不频繁打断；删除、发送、部署等高风险操作，仍然遵守原来的权限确认。

这里还有一个边界必须说清楚：我本机看到它仍标记为 under development。这意味着不同版本、不同客户端或后续更新里的行为可能变化。打不开时先查版本和 feature 列表，不要先怀疑自己写错；出现异常时删掉这一行即可回退。

如果配置显示为 true，实际任务里却没有提问，我会继续排四项：当前启动的是不是刚才验证的同一个 Codex；修改配置后是否重启了会话；config.toml 有没有重复的 [features]；这次任务是否真的存在会改变结果的分叉。最后一项很重要——功能没有在无歧义任务里打断你，可能恰好说明它工作正常。

反过来，如果它开始逢事就问，也不要把所有确认都留下。先把目标、范围、禁止项和验收写进首条指令，再观察问题是否减少。一个需要十次追问才能开始的任务，往往不是开关太谨慎，而是任务描述还没有形成可执行边界。

05 开关不能替你写清任务边界

我不会因为开启了确认，就把提示词重新写成“帮我弄一下”。更稳的做法仍然是把四件事写在第一条指令里：目标是什么、允许动哪些文件、什么不能做、怎样算完成。

这个开关真正补的是最后一层保险：当上下文里仍有一个会改变结果的选择时，Codex 不替你拍板。

我对 Agent 的判断也越来越明确：自动化的上限，不取决于它能连续跑多久，而取决于它在什么时候知道该停。

长任务开跑前，可以先打开「重置雷达」查看当前额度状态和未来 24 小时研判：

点击进入「重置雷达」小程序