on-request 弹窗哪些是正常的
approval_policy = "on-request" 不是“永远不问”。它的意思是：Codex 先在沙箱里做事，遇到越界动作再问你。
所以你看到弹窗时，先判断它问得合不合理。联网、写项目外目录、执行高风险命令、申请更高权限，这些场景本来就会问。真正异常的是：读文件、搜索代码、看 git diff、改当前项目里的普通文件也反复问。
| 字段 | 值 |
|---|---|
| 正常弹窗 | 访问网络、写工作区外目录、运行高风险命令、请求提升权限 |
| 异常弹窗 | 读文件、搜索代码、git status、git diff、工作区内常规编辑 |
| 完全不问 | approval_policy = "never"，只适合可信自动化或一次性受控场景 |
如何确认配置真的生效
先不要在原来的会话里猜。用命令行参数启动一次，看看 workspace-write + on-request 这组配置在你机器上是否正常工作。
如果这次正常，问题在配置文件、profile 或启动脚本。如果这次仍然不正常，再看版本、公司策略或系统权限。
codex --sandbox workspace-write --ask-for-approval on-requestconfig.toml 应该改哪一个
Codex 至少可能读两个配置文件：用户级 ~/.codex/config.toml，项目级 .codex/config.toml。你改错文件时，界面看起来就像“配置不生效”。
先只查 approval_policy 和 sandbox_mode。不要把整个配置文件贴出去，里面可能有 provider、MCP 或本地路径。
Select-String -Path "$env:USERPROFILE\.codex\config.toml", ".\.codex\config.toml" -Pattern "approval_policy|sandbox_mode" -ErrorAction SilentlyContinue推荐的最小权限配置
日常项目修改用这组就够了：允许 Codex 在当前工作区读写，网络和工作区外动作继续问你。
想做成个人默认，就放进 ~/.codex/config.toml。只想让某个项目生效，就放进这个项目的 .codex/config.toml。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false项目配置没生效先查哪里
如果你只改了项目里的 .codex/config.toml，但 Codex 把当前项目当作 untrusted，项目配置会被跳过。用户级配置仍然会加载，所以你会感觉“我明明改了项目配置，但行为没变”。
陌生仓库不要为了少一个确认框直接信任。先看 .codex/config.toml、hooks 和 rules 有没有会执行命令、访问网络或改文件的配置。
- 只在某个项目里不生效：优先查项目 trust 状态
- 所有项目都不生效：优先查
~/.codex/config.toml、profile 和启动参数 - 换到子目录后行为变化：检查更靠近当前目录的
.codex/config.toml - 启动时出现配置警告：先按警告里的字段名处理
启动脚本和 profile 会覆盖什么
Codex 启动参数可以覆盖 config.toml。如果你用别名、脚本、终端 profile 或启动器包装了 codex，里面可能已经带了 --ask-for-approval untrusted、--sandbox read-only 或 --profile xxx。
如果你用 --profile xxx 启动，Codex 还会加载 ~/.codex/xxx.config.toml。很多“我改了 config.toml 没用”的问题，其实是 profile 文件里还有另一套权限配置。
Get-Command codex -All
Get-Alias codex -ErrorAction SilentlyContinue
Get-ChildItem "$env:USERPROFILE\.codex" -Filter "*.config.toml" | Select-String -Pattern "approval_policy|sandbox_mode"字段名写错了怎么发现
approval_policy 写错、放错表、或者混入旧版 profile 写法时，Codex 可能没有按你预期读取。用 strict config 启动一次，让 Codex 对不认识的字段报错。
如果 strict config 报字段错误，先修字段名和层级，再回到最小配置验证。
codex --strict-config --sandbox workspace-write --ask-for-approval on-requestsandbox_mode 和 approval_policy 有什么区别
approval_policy 控制什么时候问，sandbox_mode 控制哪些动作能直接做。只改 approval_policy，但沙箱仍然是 read-only，Codex 想写文件时还是会问。
如果你的目标是让 Codex 在项目里改文件，要同时确认 sandbox_mode = "workspace-write"。如果你只想让它读代码和做 review，read-only 下询问写入动作是正常的。
| 字段 | 值 |
|---|---|
| 只读排查 | sandbox_mode = "read-only"，写入动作会被限制 |
| 日常项目修改 | sandbox_mode = "workspace-write"，工作区内写入更顺畅 |
| 全权限 | danger-full-access 加 never 风险很高，不适合作为默认值 |
公司账号或权限配置关不掉确认怎么办
企业或团队环境可能有 managed configuration、requirements 或 permission profile。管理员可以限制审批策略、沙箱模式、网络能力和可用权限组合。你本地写了 approval_policy = "never"，Codex 也可能回退到公司允许的策略。
看到启动提示、策略警告或组织管理信息时，不要继续在本地配置里硬改。先看当前账号允许哪些审批策略。
- 本地写了
never，启动后仍变成on-request - 全权限参数被拒绝或自动降级
- 同一套配置在个人账号能用，在公司账号不能用
- 启动输出里出现 managed、policy、requirements 或 permission profile 相关提示
- 团队配置只允许
read-only或workspace-write，不允许danger-full-access
常见弹窗场景怎么判断
如果你已经改成最小配置，仍然一直弹确认，按现象缩小范围。重点不是背配置项，而是找出哪一层还在控制当前会话。
只读命令也一直确认
先查启动参数、别名和 profile。只读命令不该因为 workspace-write 加 on-request 反复确认。
只有写文件时确认
检查 sandbox_mode 是否仍是 read-only，或者当前写入路径是否在工作区外。
只有联网时确认
这是常见的预期行为。on-request 会把网络访问留给你确认，尤其是命令要下载依赖或访问外部 URL 时。
项目里的 .codex/config.toml 没效果
先看项目是否 trusted。untrusted 项目会跳过项目 .codex/ 层，包括项目配置、hooks 和 rules。
写成 never 还是被改回 on-request
优先查组织 managed configuration 或启动提示。团队策略可以限制 never 和全权限沙箱。