为什么 on-request 还会弹窗

`approval_policy = "on-request"` 不是“永远不问”。它的意思是：Codex 先在沙箱里做事，遇到越界动作再问你。

所以你看到弹窗时，先判断它问得合不合理。联网、写项目外目录、执行高风险命令、申请更高权限，这些场景本来就会问。真正异常的是：读文件、搜索代码、看 `git diff`、改当前项目里的普通文件也反复问。

如何确认配置真的生效

先不要在原来的会话里猜。用命令行参数启动一次，看看 `workspace-write + on-request` 这组配置在你机器上是否正常工作。

如果这次正常，问题在配置文件、profile 或启动脚本。如果这次仍然不正常，再看版本、公司策略或系统权限。

codex --sandbox workspace-write --ask-for-approval on-request

config.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-request

sandbox_mode 和 approval_policy 有什么区别

`approval_policy` 控制什么时候问，`sandbox_mode` 控制哪些动作能直接做。只改 `approval_policy`，但沙箱仍然是 `read-only`，Codex 想写文件时还是会问。

如果你的目标是让 Codex 在项目里改文件，要同时确认 `sandbox_mode = "workspace-write"`。如果你只想让它读代码和做 review，`read-only` 下询问写入动作是正常的。

公司账号为什么关不掉确认

企业或团队环境可能有 managed configuration。管理员可以限制审批策略、沙箱模式、权限 profile 和网络能力。你本地写了 `approval_policy = "never"`，Codex 也可能回退到公司允许的策略。

看到启动提示、策略警告或组织管理信息时，不要继续在本地配置里硬改。先看当前账号允许哪些审批策略。

• 本地写了 `never`，启动后仍变成 `on-request`
• 全权限参数被拒绝或自动降级
• 同一套配置在个人账号能用，在公司账号不能用
• 启动输出里出现 managed、policy、requirements 相关提示

常见弹窗场景怎么判断

如果你已经改成最小配置，仍然一直弹确认，按现象缩小范围。重点不是背配置项，而是找出哪一层还在控制当前会话。

参考来源

相关文章