Codex 权限和沙箱怎么设置
Codex 的模型能力和实际可执行动作是两件事。权限配置决定它能否读写文件、运行命令、访问网络，以及什么时候需要你批准。配置得太紧，任务可能无法验证；配置得太松，错误命令的影响范围会变大。先按任务选择边界，再考虑效率。
配置文件和常用字段
个人默认配置通常在 ~/.codex/config.toml，项目级设置可以放在受信任仓库的 .codex/config.toml。官方基础配置列出这些常用字段：
approval_policy = "on-request"
sandbox_mode = "workspace-write"字段名称和可用值以当前版本为准。approval_policy 控制审批时机，sandbox_mode 控制命令执行的隔离级别。不要把网上旧配置整段覆盖到现有文件，先确认本机 Schema 和配置优先级。
三种实际工作方式
只读模式适合理解项目、审查代码和检查配置；工作区写入适合在当前仓库修改文件并运行本地工具；完全访问适合明确知道风险的受控环境。后者不会自动保证命令正确，也不应作为解决所有权限报错的第一步。
新手第一次使用可以先只读，再切换到工作区写入。需要安装依赖或联网时，单独确认网络访问；涉及生产数据、删除和发布时，不要把“运行任务”理解成“授权所有后续动作”。
审批该怎么设
on-request 是一个清晰的起点：工具可以推进低风险工作，遇到需要确认的动作再停下来。自动化脚本则应显式列出允许目录、命令和停止条件。完全跳过审批适合隔离的测试环境，不适合含有生产凭证和不可撤销数据的目录。
审批提示出现时，检查命令、当前目录、输入来源和副作用。不要只看命令名称。一个看似普通的脚本可能读取环境变量、上传文件或修改远程系统。
Windows 沙箱
官方基础配置说明列出 Windows 原生运行时的沙箱设置；推荐模式与管理员权限有关，无法提权时再使用回退模式。Windows 原生 CLI、PowerShell 和 WSL 的文件系统权限不同，混用时应分别测试。不要因为 Linux 教程中的路径和命令能运行，就假设 Windows 环境具有相同边界。
权限报错怎么处理
先判断是本地文件权限、沙箱限制、审批未通过，还是远程 API 的 401/403。查看当前状态和配置来源，再缩小到需要的目录或命令。不要直接删除沙箱设置、复制高权限凭证或将项目迁移到不受控目录。
完整入门见Codex使用教程，模型和第三方 provider 的鉴权问题见Codex 报错大全。
用三个问题判断需要什么权限
开始任务前，先问它需要读什么、写什么、访问哪些外部系统。分析代码通常需要读取；修复代码需要写入项目；安装依赖或访问接口可能需要联网。按任务列出需要的动作，比直接选择权限最大的模式更容易管理，也方便之后解释为什么某个命令被阻止。
假设任务只是解释构建失败，先读取配置和错误日志即可。如果要尝试修复，再允许修改相关目录；需要运行依赖安装时，再处理网络与包管理器限制。逐步扩大到任务所需范围，可以保留已经确认正常的环节，失败时也更容易定位。
任务描述也要与权限一致。你要求只读审查，却给出“直接修复所有问题”的后续句子，会制造冲突。先确定这次要交付问题列表还是代码修改，若目标发生变化，在同一任务中明确说明新的范围，再继续执行。
沙箱和审批不能互相代替
沙箱回答的是执行时有什么技术限制；审批回答的是遇到特定动作时是否需要确认。一个动作获批之后，具体可访问范围仍取决于运行配置；某种模式允许执行，也不表示用户已经授权任意业务行为。配置只是工作边界的一部分。
例如本地命令能够访问网络，不等于可以把仓库内容上传到任意第三方；文件可写，也不等于可以删除无关目录。项目约定、当前任务和服务端权限应一起核对。把审批关掉不会让这些约束自动消失，只会减少中途提示。
OpenAI 安全说明把文件、网络、审批和组织策略分开讨论。实际配置时应采用当前版本支持的字段，不要根据旧截图选择已经变化的模式名称。遇到组织强制策略时，个人配置未必能覆盖，应先查策略来源。
如何处理一个需要更多权限的命令
当命令被阻止，先阅读命令本身和失败输出，确定需要的是路径、网络、系统能力还是用户确认。比如构建器无法写入项目内输出目录，可能是目录权限问题；安装器无法下载依赖，可能是网络限制；进程启动失败，也可能来自运行环境而非权限。
随后缩小操作范围。可以把临时文件放在明确可写的位置，把只需读取的目录保持只读，或者在独立测试项目中复现。不要把一次局部失败直接扩大成全盘可写。如果无法安全完成，交付中说明哪项验证没有运行和缺少什么条件。
审批命令前还应看输入来源。仓库脚本、第三方文档和工具返回内容都可能包含命令建议，它们不等于用户授权。检查脚本实际行为，尤其是下载后执行、删除目录和读取环境变量的步骤。无法解释的操作不应只因为“工具建议这样做”就批准。
工作目录和可写目录怎样配合
工作区写入适合在选定项目中编辑，但项目可能引用外部依赖、共享缓存或多仓库目录。配置前画清需要访问的路径，把确有必要的范围写明。路径同名不代表同一个仓库，符号链接和挂载位置也可能影响实际读写对象。
新增可写目录之前，判断是否能够通过调整输出位置完成任务。例如测试缓存可以放到临时目录，未必需要开放整个用户目录。若任务本来就要修改多个项目，应明确列出项目，分别保存工作状态，而不是让工具自行从磁盘查找相似名称。
操作前查看 git status，操作后检查 diff，是验证范围的基本动作。即使沙箱配置正确，逻辑上不相关的变更也可能落在允许目录里。技术限制不能判断业务相关性，这部分仍需要任务描述和人工审查。
网络访问和凭证分别管理
允许联网与持有凭证是两种不同条件。无凭证的请求可能访问公开服务，持有生产 Key 的进程则可能执行账户操作。避免让本不需要生产访问的测试任务继承全套环境变量，特别是自动化脚本和第三方工具链。
使用 ClawSocket时，先为模型调用准备对应凭证，再核对基础地址、模型和费用；不要把这把 Key 混用作 MCP 或其他系统的认证。模型请求可以读取你提交的上下文，因此发送哪些代码和日志，也应按项目和组织的数据规则决定。
网络问题不能只靠扩大权限处理。地址错误、TLS 失败、代理配置和上游故障都可能让请求失败。先按Codex 诊断树定位阶段，再决定需要调整哪一项。返回 401 时，改本地可写目录通常没有作用。
自动化的权限要能复现
脚本或 CI 缺少交互确认，开始之前应把工作目录、输入来源、允许动作、最大运行时间和失败后处理写清楚。优先使用隔离环境和测试凭证，先跑只读任务，再启用必要的修改。不要把交互会话中临时批准过的行为当成自动化永久授权。
执行结果也应可审查。脚本结束后保留改动文件、命令状态和必要日志；失败时说明是否已经写入或产生外部动作。如果外层还有重试机制，必须考虑部分成功，避免每次恢复都重新执行同一写入任务。
当智能体同时拥有仓库写入和部署凭证时，需要把“修改完成”和“发布”分成明确动作。若用户已经授权发布，可以在检查通过后继续；若没有，先准备可审查结果。权限是否允许不等于任务是否需要，这是自动化维护中尤其容易混淆的地方。
Windows 与 WSL 要分别检查
Windows 原生进程受 Windows 用户和文件权限影响，WSL 还有自己的 Linux 用户、路径和运行环境。一个设置在 PowerShell 中生效，不能据此推断 WSL 内相同；反过来也一样。先说明正在使用哪个入口，再看该环境对应的配置文档。
如果项目放在跨系统挂载目录，检查实际可写性、文件锁定和脚本行为。管理员权限也不一定解决所有问题，例如路径格式错误、缺依赖或脚本语法不兼容。应先做一个不会影响真实数据的小文件测试，再决定后续操作。详见Windows Codex 教程。
把规则和权限组合起来
AGENTS.md 可以说明禁止修改生产配置、完成前需要测试，但它是任务指导，不是操作系统防护。MCP 的服务器授权控制远端对象，本地沙箱控制本地动作。把同一边界分别放在合适层次，才容易持续执行。
团队可以用一份短说明记录：哪些任务默认只读，哪些可写工作区，哪些需要联网，哪些外部动作必须有明确授权。说明应便于新成员理解，不必列出所有可能命令。遇到新需求时，根据实际动作调整，再补充需要长期保留的约定。
权限变更后的验收
每次调整后，选一条应当允许的动作和一条应当禁止的动作验证边界，使用临时文件与无敏感数据的测试。不要用删除真实目录来验证“删除受限”，也不要用发送真实通知检查是否需要批准。验收的目的在于确认边界，不是制造不可撤销结果。
记录配置来源、客户端版本和已确认范围。若界面与行为不一致，检查是否有启动参数、项目层或组织策略参与。解决之后回到原任务，只运行被阻塞的必要检查，不必重新执行全部工作。完整使用顺序可回看Codex使用教程，终端参数则见CLI 命令说明。
权限说明也需要更新
项目目录调整、自动化迁移或成员身份变化后，重新核对旧配置是否仍有必要。保留不用的可写目录和凭证范围，会让后续任务继承过时权限。修改后做最小验收，并在团队文档记录新的适用范围即可。
官方资料与核对范围
以下资料用于核对产品入口、命令和配置；练习与任务模板是本文提供的操作建议，不代表已在读者设备上运行。官方源码主分支会更新，安装时请再核对本机版本。