理解Codex权限与批准设置：如何从较小工作范围开始

摘要： 将Codex权限分为可访问文件与网络的边界，以及越过边界时的批准方式，更容易理解。先确定工作文件夹与成果，再选择读取、修改和安装所需范围。批准问题减少，并不意味着访问范围缩小；授予广泛权限，也不意味着代码质量提高。

1. 分别理解三种设置

OpenAI官方沙盒文档说明，沙盒规定命令的文件与网络访问边界，批准策略决定何时请求额外批准，批准审查者决定请求由用户还是自动审查者判断。选择自动审查，并不会自动扩大既有沙盒边界。

实践中可用三个问题理解：“能访问哪里？”“能请求被阻止的操作吗？”“由谁判断？”例如修改项目内文字可能在当前边界内可行，而读取其他仓库资料或下载依赖可能需要另行访问。实际是否可行，应依据当前生效设置确认。

提示词中的“只修改此文件夹”是工作指令，并不等同于技术上的文件阻止。反之，以只读设置运行时，即使写“直接修改文件”，也不会凭指令获得写入权限。需要两个步骤：用文字确定任务范围，再确认实际权限设置与范围一致。

2. 按任务选择工作范围的表格

下表是作者编写的选择标准，并非解释所有环境的默认值，而是用于判断本次工作需要哪些访问的指南。开始时可将成果收窄为一个，再根据过程中发现的需求调整范围。

所需成果	首先需要的范围	判断额外访问时
说明代码结构与错误原因	读取相关源代码与配置	确认没有假设已读取不存在的文件
修复搜索输入错误	写入项目相关文件并进行本地验证	确认测试产生的缓存与结果文件位置
安装新软件包	修改安装目标文件与使用必要网络	确认目标包、下载来源与安装脚本
比较其他仓库的公共模块	读取该仓库的必要文件	区分是否需要对两个完整仓库具有写入权限
向外部服务发布结果	服务连接与对应写入操作	区分起草与实际发布的对象、权限

选择项目文件夹时，可采用包含源代码、配置和必要测试的最近共同文件夹。打开整个文档文件夹或多个客户项目，可能将无关资料也加入工作上下文。公共模块在外部时，应先决定允许读取所需文件，还是作为独立项目处理。

只读调查也需要确定结果保存路径。如果要求“仅审查”，同时要求创建本地报告文件，仍需要写入。应区分在界面获得说明，与创建报告文件，减少设置选择错误。

3. 在应用与CLI中确认实际设置

官方权限模式文档建议普通任务从Ask for approval开始。此模式允许工作区内读取、修改与普通本地命令，越过边界的任务会请求批准。桌面应用与IDE使用输入框下的权限菜单，CLI使用/permissions；CLI的/status也可检查工作区。

桌面应用未显示额外模式时，可检查当前文档的Settings > General > Permissions。启用模式在菜单中显示，与在当前对话中选择模式，是不同操作。组织政策也可能限制选择。找到菜单名称，并不意味着既有对话的权限已经改变。

如果希望通过CLI明确意图启动，可以使用下方官方支持选项。第一行用于以读取为主的调查，第二行用于项目修改。它们不是依次执行的流程，而是按自己的任务选择其中一行的示例。

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

官方批准与安全文档说明了这些组合与受保护路径。即使设置workspace-write，.git、.agents、.codex等路径也有独立保护。因此不能因为位于工作文件夹内，就假设允许写入所有配置文件。

写配置文件时容易混淆的部分

以下是表示传统沙盒方式中项目修改默认设置的小示例，并非要求用它覆盖整个实际配置文件。应检查既有设置与组织要求，只判断需要应用的项目。

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

当前权限配置文件文档也介绍了测试版方式default_permissions与[permissions]。此方式与既有sandbox_mode并非合并应用的设置，不能混用不同示例。使用新配置文件前，宜先确认该文档的兼容条件。

Windows也支持原生沙盒与权限配置文件。不能仅因为发生错误就断定必须使用WSL，应先确认运行环境与生效政策。同一电脑上的原生Windows任务与WSL任务，也可能有不同路径和已安装工具。

4. 可复制修改的预先确认提示词

以下是作者编写的假想搜索应用任务。请将方括号换成自己的路径与要求。初次可用于读取资料、说明必要访问，并了解工作准备状态。

작업 목표: [검색어 앞뒤 공백 때문에 검색이 실패하는 원인 설명]
대상 프로젝트: [실제 프로젝트 경로]
조사 범위: [검색 입력 컴포넌트, 호출 함수, 관련 테스트]
현재 작업 폴더와 확인 가능한 권한 설정을 알려 주세요.
먼저 관련 파일을 읽고 원인 후보와 근거 위치를 정리해 주세요.
이 단계의 결과는 대화에 작성해 주세요.
추가 접근이 필요하면 대상 경로·서비스, 목적, 예상 변경을 설명해 주세요.
확인하지 못한 설정이나 자료는 미확인이라고 표시해 주세요.

此请求应得到的是必要文件与验证方法清单，而非“所有权限都安全”的声明。读取搜索组件后仍找不到原因，可能需要实际错误信息或请求数据。此时提供去除个人信息的复现输入，也能在不扩大文件访问的情况下帮助调查。

执行任务时，应同时加入所需行为与完成标准。下句是范围指令的示例，不会修改应用权限设置。

수정 목표: [검색어 앞뒤 공백만 제거하고 기존 검색 동작 유지]
수정 대상: [확인한 파일과 관련 테스트]
기존 API 요청 형식과 다른 화면의 동작을 유지해 주세요.
프로젝트에 이미 설치된 도구로 관련 검증을 진행해 주세요.
추가 설치가 필요하면 패키지·출처·파일 변경·설치 스크립트를 설명해 주세요.
최종 결과에 수정 파일, 실행한 명령, 결과, 미실행 검증을 적어 주세요.

5. 阅读批准请求的五个问题

批准界面应查看输入与结果去往哪里，而不只看命令名称。同为“安装依赖”，在项目内创建文件的安装，与安装全局工具，修改位置不同。判断下载内容是普通数据还是待执行脚本，也有帮助。

1. 对象： 访问哪个文件夹、主机、仓库或服务？
2. 输入： 读取或发送哪些文件与值？
3. 修改： 新建、修改或删除什么？
4. 必要性： 为什么当前请求需要此操作？
5. 范围： 允许一次、本次任务，还是整个会话？

说明不足时，可以要求“解释此命令的文件修改、外部通信、安装后执行的代码，以及范围更小的替代方案”。在批准界面提供的范围中选择足够完成任务的范围。如果相同请求反复出现，应检查批准对象是否每次变化，而不是一律扩大允许范围。

自动审查也可能判断错误。获批准只表示操作通过审查，并不保证执行成功或结果准确。获批准的安装失败后，下一步应读取安装日志与文件状态。仅重新请求同一命令，无法解决原因。

6. 遇到阻碍时区分原因的表格

可见症状	首先确认什么	下一行动
找不到文件	拼写、相对路径基准与文件实际存在情况	确认准确路径，指定读取文件
访问被拒绝	读取与写入差异、工作边界与操作系统权限	仅重新判断失败对象与必要访问
安装下载失败	阻止信息、DNS、代理与仓库响应	区分网络政策与服务错误
测试命令失败	可执行文件、依赖与实际测试错误	分别记录工具准备问题与代码失败
无法选择权限模式	组织要求与当前设置	先开展允许范围内可执行的工作

例如测试写入临时文件时失败，只有源代码修改权限可能不够。应确认必要写入位置，并检查能否使用项目内结果路径。反之，测试因预期值不符失败，扩大权限也无法解决。应先区分失败信息中哪部分表示访问限制。

approval_policy = "never"表示不询问批准，并非关闭沙盒。边界外操作可能失败，因此自动执行也需要设计必要访问与失败报告。Full access允许广泛文件修改与网络执行，不宜作为解决错误的默认选择。

7. 工作后验证结果，而不只是权限

修改完成后，先比较请求文件与实际修改文件是否一致。出现预料外的锁定文件、配置文件或生成文件时，应确认变化原因。也应区分用户原先编辑的变更与本次变更。即使修改清单很短，未检查核心行为时，完成依据也可能不足。

• 是否分别检查问题输入与正常输入？
• 报告的命令是否实际执行并保留结果？
• 是否分别标明失败验证与无法执行的验证？
• 外部发布或安装的目标与结果是否符合请求？
• 临时允许的额外访问，其适用范围是否已经结束？

假想搜索应用可通过带空格的“ 金属 ”、无空格的“金属”与仅空白输入确定预期行为。同时查看修改文件与验证结果，可避免混淆访问获允许与需求已解决。本文章示例仅用于说明，并非运行或测试该项目的案例。

8. 初次开始的实用顺序

确认项目文件夹，确定读取或修改目的，然后检查当前权限。必要行为越过边界时，阅读对象与目的，判断额外范围。最后检查修改文件与验证结果。熟悉此顺序后，就能说明本次任务所需访问，而不只是选择权限菜单中最广泛的选项。

官方来源与确认日期： 权限模式, 沙盒, 批准与安全, 权限配置文件。2026年10月3日确认。配置示例应按当前环境与组织政策调整。