团队安全使用 Codex：检查文件、网络与审批权限

2026年10月4日

大约花 30 分钟，团队负责人就能为 Codex 建立一个试用配置，检查它可以修改哪些位置、何时需要审批，以及命令能否访问网络。你需要一个测试代码库、一位技术政策负责人，并在代表性成员的电脑上安装 Codex CLI。最后得到的是允许与阻止操作的测试记录，而不是“打开一个开关就能消除所有风险”的承诺。

本文讨论通过 CLI、桌面应用或 IDE 扩展在本机运行的 Codex。如果你刚开始用 CLI 修改代码，可以先读在陌生代码库中完成并验证一个小改动。下文重点是团队共同的操作边界。

准备工作

建立一个不含真实密钥或客户数据的测试代码库。选出一个允许修改的文件、一个代码库外的文件、一个允许访问的域名，以及一个应当被阻止的域名。

阅读 OpenAI 的 Agent approvals & security 和 Auto-review 指南。诸如“创建拉取请求前运行测试”这样的团队工作规则，可以写入Codex 的 AGENTS.md。但项目文档中的文字不会自动形成操作系统级限制。文件、网络和审批权限需要分别配置并测试。

明确谁可以修改政策，以及升级后何时复查。

操作步骤

第一步：根据实际任务选择模式

Codex 有两个不同的控制层。沙盒决定命令可在哪里读写文件，以及能否访问网络。审批政策决定 Codex 越过边界前何时必须请求许可。根据 OpenAI 文档，workspace-write 允许它在工作区内读写，而命令的网络访问默认关闭。在 on-request 政策下，修改工作区外的文件或运行需要网络的命令，可能产生审批请求。

第一次查看代码库时，先用只读模式：

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

在测试代码库中执行已分配的修改时，可以使用：

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

在 CLI 中，/permissions 可以查看或调整当前会话模式，/status 显示 Codex 识别到的工作区。不要只为了省去审批提示就开启 danger-full-access，因为它会移除本机沙盒边界。

如果团队成员还需要了解 AI 辅助编程的基础，可以看面向新手的 Vibe Coding 指南。团队负责人仍要审查任务范围和生成的代码。

第二步：确定需要保护的路径

在默认 workspace-write 政策中，OpenAI 列出可写区域内受只读保护的路径：.git、.agents 和 .codex，具体适用条件以文档为准。如果 .git 是指向真实 Git 目录的指针文件，解析后的 Git 目录也受保护。这是针对这些路径的特定保护，并不表示代码库里其他敏感文件都自动安全。

另外列出环境文件、证书和数据导出文件。对于测试版 permission profiles，Permissions 文档介绍了按路径设置 read、write 和 deny，包括拒绝读取 .env 文件。Permission profiles 不能在同一会话中与旧沙盒设置组合使用。选择一种配置体系，并在代表性电脑上验证。

给 Codex 一个边界清楚的测试请求：

在此测试代码库中，仅修改 [允许的文件路径]，完成 [改动说明]。
修改前列出预计会接触的文件。不要读取密钥，不要修改代码库外的文件。
修改后运行 [安全的测试命令]，并列出实际变化的文件。

把 Codex 的列表与实际变更文件对照。在测试环境中尝试一次越权操作，确认它被阻止或需要审批。仅有 AGENTS.md 不能证明路径已经被锁定。

第三步：把网络当作独立权限

在 workspace-write 下，本机命令的网络访问默认关闭。如果流程必须调用某个服务，先确认准确域名、用途，以及允许发送的数据。OpenAI 将两个动作分开：允许命令联网，以及启动限制目标地址的代理。只写域名列表不会自动开启代理；允许联网而没有启动代理，命令可能直接访问外网。

下面是用于测试环境的本机配置示例：

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

[sandbox_workspace_write]
network_access = true

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

请替换成公司批准的域名，并分别测试允许及被阻止的连接。命令代理不负责过滤网页搜索、浏览器、应用、MCP 或 Codex Cloud，这些入口有各自的控制措施。

如果团队使用当前版本的 Codex Cloud，可参考从云端修复问题到拉取请求的流程以及最新的 Connect to services 文档。Codex Cloud (Legacy) 的网络说明针对旧系统，不应照搬到新环境。云端权限也不能代替成员电脑上的沙盒政策。

第四步：启用 Auto-review 前先理解其作用

使用 approval_policy = "on-request" 时，越过边界的请求通常交给用户处理。若设置 approvals_reviewer = "auto_review"，独立的审查代理会在执行前审核本来就需要审批的请求。它不会授予更多权限、自动联网或削弱受保护路径。沙盒内本来允许的操作可以不经过这项审查。

一种试用配置是：

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

导出数据、修改生产环境和难以撤销的操作，仍需要责任人的审批。Auto-review 拒绝请求后，阅读理由，不要改写命令绕开同一边界。超时不证明操作危险，但也表示操作尚未执行。

第五步：同时测试允许和阻止的情况

不能仅因为 Codex 成功修改一个文件，就断言政策正确。在测试代码库中记录四项检查：修改范围内文件、尝试修改范围外文件、访问允许域名、访问禁止域名。每项都记录模式、请求或命令、真实结果和复核人。如果启用了 Auto-review，还要记录审查决定与理由。测试日志不需要包含密钥。

使用普通成员账号重复测试，并在每次政策变更后重新测试。对于云端，分别测试代码库、环境和网络权限。交接记录应写明启用了什么、谁能修改以及测试结果。

结果示例

一个使用样例代码库的团队可能这样记录：“Codex 可以修改测试工作区内的 src/；尝试修改工作区外文件会请求审批；默认沙盒下 .git 保持只读。获准的 API 命令经过代理，被禁止的域名无法连接。Auto-review 只检查越过边界的请求。合并前由团队负责人检查差异和测试结果。”这是记录格式示例，并非保证每台电脑、每个客户端版本或套餐都会得到同样结果。

如果某项检查表现不同，暂缓扩大使用。查看实际生效的配置和运行路径，特别留意测试版 permission profiles 与旧沙盒设置同时存在的情况。用未来真正要使用的账号、电脑和环境再次验证。