当你让 Codex “做一个后台”，真正决定结果的往往不是它会不会写代码，而是它有没有在动手前问清楚：数据放哪、登录怎么做、先改哪一块。
Codex 现在有一个可手动打开的功能开关：default_mode_request_user_input。把它写进 ~/.codex/config.toml 后，Codex 在普通的 Default 模式也可以调用 request_user_input，向你展示带选项的结构化问题，而不只是在 Plan 模式提问。官方源码对这个功能的定义很直接：允许在 Default 协作模式使用 request_user_input。源码
这不是模型能力升级，也不是“打开后 Codex 一定会问更多问题”。它改变的是普通模式里一项工具的可用性：当任务确实存在关键分支时，Codex 可以把问题做成可选择、可确认的输入，而不是猜一个方案继续往下做。
信息截止：2026 年 8 月 22 日。 本文的功能字段与含义以 OpenAI 公开的 Codex 源码和配置 schema 为准；普通模式下未回答问题的等待行为仍在演进，文末会单独说明边界。
先看设置：只需一段 TOML
打开配置文件：
~/.codex/config.toml
如果文件中还没有 [features]，加入：
[features]
default_mode_request_user_input = true
如果已经有 [features]，只在这一节下追加这一行即可：
default_mode_request_user_input = true
保存后重新启动 Codex，再开始一个新任务，能避免旧会话沿用启动时已加载的配置。OpenAI 的公开配置 schema 已将 features.default_mode_request_user_input 列为布尔值；因此要注意 TOML 层级，别把它误写到 [features] 之外。配置 schema
它和普通一句“你想怎么做？”有什么区别
区别不在于 Codex 突然学会了提问，而在于提问被变成了一个可以明确收集决策的工具调用。
| 场景 | 普通文本提问 | request_user_input 结构化提问 |
|---|---|---|
| 需求有多个合理方案 | Codex 用一段文字说明，再等你自由回复 | 可给出互斥选项、推荐项和每个选项的影响 |
| 需要确认范围 | 容易出现“先按默认做”的隐含假设 | 可把范围、优先级、存储方式等关键选择显式化 |
| 你要快速决策 | 需要自己从段落里抽取选项 | 直接点选，再继续执行 |
| 需求本身已很明确 | 通常足够 | 不应为了弹窗而弹窗 |
比如你说：“修一下这个线上报错。”没有这个能力，Codex 可能只问一句“要不要顺便重构？”，也可能把“顺便”理解成授权，直接扩大改动范围。开关打开后，它可以先把范围分支摆出来：
上图是根据结构化提问能力制作的原创示意，并非 Codex 官方界面截图。它想表达的不是某个固定 UI，而是问题应该怎样被问清楚：
只修当前问题：改动最小，优先保持接口与数据结构不变；顺便做局部重构：有机会减少后续维护成本，但要接受额外的验证范围；先查看代码再决定：先完成诊断，暂不直接修改项目文件。
同样的逻辑也适用于新功能的底层取舍，例如：
收藏数据存在哪里？
○ 本地 JSON（最快做出可用原型）
○ SQLite（推荐：适合单机工具和后续筛选）
○ 云数据库（适合多端同步，但需要账号与部署）
重点是：它把“模型的猜测”换成“用户的选择”。 选项仍然由 Codex 在具体任务中决定，开关本身不规定要问什么，更不会替你选答案。
最适合打开的四类任务
这个功能并不只适合从零写代码。只要一个早期选择会改变实现路径，它就有价值。
1. 从零做工具或小产品
新项目最容易在“看似小”的地方分叉：本地优先还是云端优先、是否需要登录、先做桌面端还是 Web。让 Codex 用结构化问题把这些决定放在第一屏，通常比先生成一套完整脚手架再推倒更省时间。
2. 需求描述还不够具体
“做得高级一点”“加一个 AI 功能”“优化性能”都不是可直接落地的规格。此时更好的流程是先确认目标用户、验收标准、可动的范围，再写代码。request_user_input 适合承载这种少而关键的澄清，不适合把每个实现细节都抛回给用户。
3. 修改已有项目
改老项目尤其需要先对齐：能不能改数据库、是否兼容旧接口、是局部修复还是顺便重构。结构化选择能把“只修 Bug”和“重做这一层”这样的范围差别讲清楚，减少做了一半才发现目标不一致的情况。
4. 多种实现都成立
例如状态管理选本地状态、URL 参数还是全局 store；导入功能选浏览器直传还是服务端中转。没有唯一正确答案时，让 Codex 写清每个方案的后果，再让用户做取舍，往往比把偏好伪装成技术结论更可靠。
它不会解决的事，也要先说清
第一，它不改变 Default 模式的协作原则。默认模式仍偏向在合理假设下推进；这个开关只是让 Codex 在需要时拥有结构化追问的入口，并不意味着每个任务都会被打断。
第二，它不等于需求评审系统。选项质量取决于 Codex 是否识别到了真正的决策点。问题问得太宽、选项遗漏、没有写清代价，仍可能让人误选。因此，关键选择最好包含“推荐方案 + 适用条件 + 代价”，而不是只列名词。
第三，普通模式里的等待体验目前仍有边界。OpenAI GitHub 上已有用户报告：在某些较新的 CLI 版本中，Default 模式发出的这类问题若无人回应，可能在短时间后自动结束；该帖是社区 issue，不是 OpenAI 对产品行为的承诺。相关 issue 因此不要把它用于必须长时间挂起、等待审批才可继续的生产流程；这种情形仍应选择明确支持阻塞式确认的工作流。
一个更实用的使用原则：只问“改方向”的问题
开启后，最理想的体验不是弹窗变多，而是返工变少。可以用下面这张判断表决定是否值得让 Codex 先问：
| 这个问题是否会… | 建议 |
|---|---|
| 改变数据结构、部署方式或安全边界 | 应该先问 |
| 让工期、成本或第三方依赖明显不同 | 应该先问 |
| 只是变量命名、组件拆分等可逆细节 | 可以直接做，并在结果里说明 |
| 用户已明确给出约束 | 不重复提问，直接执行 |
对使用者来说，也可以在提示词里补一句：“遇到会影响架构、数据或范围的选择，先用结构化问题问我。”这样既给了 Codex 明确的协作预期，也避免它把每个小细节都变成确认框。
值不值得开？
如果你常用 Codex 从零做功能、维护旧项目，或者经常给它一两句还没完全想清楚的需求，这个开关值得打开。它的价值不是让 Codex 更谨慎，而是让“需要你拍板的地方”更早、更清楚地出现。
但也别把它理解成自动防返工按钮。真正减少返工的组合是：你给出目标和约束，Codex 把有分歧的方案讲清楚，再由你确认那几个会改方向的决定。default_mode_request_user_input 做的，正是补上中间这一环。
上手检查清单
- 在
~/.codex/config.toml的[features]下写入default_mode_request_user_input = true - 保存后重新启动 Codex，并用新任务验证配置是否生效
- 只在架构、数据、范围或成本会分叉时要求结构化提问
- 看清推荐项的适用条件与代价，再做选择
- 不把普通模式的提问当成可无限期等待的审批机制
参考资料
- OpenAI Codex 源码：
DefaultModeRequestUserInput功能定义 - OpenAI Codex 源码：
config.schema.json中的default_mode_request_user_input - 社区 issue（非官方产品承诺）：Default 模式提问的等待行为讨论