Codex CLI 权限怎么设置？/permissions、沙箱、审批策略与网络访问指南

先说结论：审批决定何时停，沙箱决定能访问哪里

Codex 的 approvals 与 sandbox 是两层独立控制。审批策略决定遇到越界动作时是否暂停等待确认；沙箱决定命令能够读取、修改哪些文件以及是否能访问网络。把 approval_policy 设为 never 只是不弹确认，不会自动获得沙箱外权限。

对日常仓库工作，官方推荐的低摩擦组合通常是 workspace-write 加 on-request：Codex 可在当前工作区读写和运行常规命令，超出目录或需要网络时再询问。只读分析用 read-only；danger-full-access 会移除边界，只应在明确隔离和充分信任的环境中使用。

一、/permissions 能改什么

在 Codex CLI 中输入 /permissions 可打开权限选择器，更改当前会话的权限配置。桌面应用和 IDE 扩展通常也在输入框附近提供权限入口。可见选项会受到客户端版本、组织策略和本地配置影响。

切换前先用 /status 查看当前工作区与配置。权限变化只应覆盖任务真正需要的范围，例如只读审计不需要写权限，构建依赖可能需要有限网络，部署操作则应明确目标和回滚方案。不要为了省一次点击直接长期开放全部目录。

二、read-only、workspace-write 与 full access 的区别

read-only 适合代码阅读、方案评估和状态检查，默认不允许直接修改文件。workspace-write 允许在当前工作区内编辑并运行常规命令，是本地开发中较平衡的模式。danger-full-access 则不受文件系统和网络沙箱边界限制。

工作区通常包含当前目录及特定临时目录，具体范围可用 /status 检查。即使 writable root 可写，默认策略仍可能保护 .git、.codex 等敏感目录。需要跨多个目录时，优先添加明确 writable roots，而不是关闭整个沙箱。

三、on-request 与 never 不是安全级别名称

on-request 表示 Codex 在沙箱内自动工作，遇到需要越界的动作时申请批准。never 表示不显示审批提示；命令仍受当前沙箱限制，无法通过的动作会失败，而不是自动升级权限。因此“不要一直问我”与“允许访问整台机器”不是同一个设置。

只读自动化可以用 read-only 加 never：不弹提示，但也不能写入。工作区自动化可以在 workspace-write 下减少提示，并用规则处理固定命令。只有同时使用 danger-full-access 与 never，才是没有沙箱、没有审批的完全访问，风险最高。

四、为什么不建议默认使用 --yolo

--dangerously-bypass-approvals-and-sandbox（别名 --yolo）会移除沙箱和审批。恶意仓库、被污染的脚本、错误命令或提示注入可能读取凭证、修改无关文件、访问网络或造成难以恢复的破坏。官方将其标记为高风险。

如果必须在自动化中使用高权限，应把 Codex 放进一次性容器、专用虚拟机或权限受控的 CI 环境，限制挂载的密钥和目录，并使用独立云凭证。外层隔离才是安全边界，不能仅依赖提示中一句“不要动其他文件”。

五、怎样在不频繁弹窗的情况下保持边界

第一种方式是把任务限定在单一仓库，并使用 workspace-write。第二种是为常用安全命令配置规则，让允许、询问和禁止的命令前缀更明确。第三种是设置 auto_review，让合格的审批请求由审查代理评估，而不是全部弹给用户。

自动审批不会改变沙箱边界，也会消耗额外模型用量。高风险动作仍需要足够授权或会被拒绝。规则应从窄范围开始，例如只允许特定包管理器在当前项目运行，不要用通配模式放开任意 shell 或整个用户目录。

六、网络访问为什么要单独配置

默认 workspace-write 模式下，命令网络通常关闭，除非在配置中启用。即使开启网络，也可以通过网络代理和域名规则限制目标。启用代理功能本身不会授予网络，必须同时允许 workspace-write 命令访问网络。

网页搜索、浏览器、MCP 和命令行程序的网络通道可能受不同控制。给 shell 开网络不代表浏览器权限相同，反之亦然。搜索结果和网页内容都应视为不可信输入，避免让外部页面中的提示诱导 Codex执行越权命令。

七、config.toml 怎样设置可重复默认值

经常使用相同模式时，可在 config.toml 配置 sandbox_mode、approval_policy、approvals_reviewer 和 workspace-write 的网络或可写根目录。配置前先确认组织管理策略是否覆盖本地设置，并在测试仓库验证实际行为。

不要把 danger-full-access 设为所有项目的永久默认。更好的做法是建立只读、项目编辑、需要网络等不同 profile，按任务选择。这样既减少每次手动调整，也让团队能够审计每类任务获得了哪些权限。

八、三类任务的推荐权限思路

代码审计和解释项目：read-only，必要时 on-request；常规开发和测试：workspace-write 加 on-request，网络按域名或任务开启；无人值守格式化或只读检查：在明确沙箱内使用 never。部署和生产变更应使用更严格的凭证、审批与回滚流程。

任务中若出现删除、递归移动、密钥读取、上传数据或修改系统服务，应重新确认目标和范围。即使当前配置允许，也不代表每个高影响动作都应自动执行。权限是技术上能做什么，授权是用户允许做什么，两者不能混为一谈。

九、团队落地检查清单

记录默认 sandbox 与 approval_policy；确认 writable roots；把生产凭证从开发环境隔离；为网络访问建立域名允许清单；对危险命令保留人工确认；在 AGENTS.md 写明测试、禁止目录和交付要求；定期复查规则是否过宽。

站内更多 Codex 工作流可访问 https://gptupcn.com/codex/ 。权限字段和可用模式会随版本更新，部署前应以当前 OpenAI Docs、客户端 /status 与组织策略为准，不要照搬旧教程中的配置。

十、无人值守任务怎样选权限

无人值守并不意味着必须使用 full access。只读报告、依赖清单和代码扫描可以用 read-only 加 never；只修改仓库内生成文件的任务可以用 workspace-write，并把输出目录设为明确 writable root；需要下载依赖时只开放必要网络目标。

定时任务还应固定仓库修订、输入来源、最大运行时间和输出位置，并在写入前做备份。删除、发布、支付、生产部署和密钥轮换等高影响操作应保留专门授权或人工门槛，不能因为任务按时运行就默认永久授权。

运行结束后记录实际使用的 sandbox、approval policy、网络访问、修改文件和验证结果。失败时应安全停止，而不是自动扩大权限重试。可审计的权限与日志，才是真正减少人工干预又不失控的基础。

结语

减少审批提示不等于取消所有安全边界。先用沙箱限定文件和网络，再选择人工审批、自动审查或 never，最后用规则和 profile 固化常用场景，才能在效率与可控性之间取得平衡。