Codex 沙箱机制：让文件写入、命令和网络访问保持可控

适用场景

这篇手册适合遇到 Codex 权限提示、命令受限或文件写入失败的用户。理解沙箱后，你可以更准确地判断哪些限制应该保留，哪些操作可以临时批准。

OpenAI 官方 Sandbox 文档介绍了 Codex 沙箱相关概念。不同运行环境的具体限制可能不同，实际行为以当前客户端、CLI 或云端环境为准。

步骤 1：理解沙箱保护什么

沙箱的目标是限制 Codex 的副作用。

它通常会约束：

• 可读取的文件范围。
• 可写入的目录。
• 命令执行能力。
• 网络访问。
• 外部应用或系统资源。

这能避免 Codex 在不相关目录里写文件、访问敏感数据，或运行超出任务需要的命令。

步骤 2：按任务声明需要的范围

如果你知道任务范围，直接写清楚。

示例：

你只需要读取 src/app/manual、src/components 和 content/manual。
只允许修改 content/manual 和 manual-sidebar.tsx。

如果需要构建：

修改完成后可以运行 next build。
如果构建需要联网安装依赖，请先停止并说明原因。

这样 Codex 不需要猜测权限边界。

步骤 3：遇到沙箱错误先判断必要性

沙箱错误不一定代表需要放权。

先问三件事：

• 这个命令是否必要？
• 它为什么要访问受限路径或网络？
• 有没有更小范围的替代方式？

例如，只是检查文章 frontmatter，不需要联网；只是读取当前项目，不需要访问用户主目录。

步骤 4：临时授权要尽量窄

如果确实需要放权，授权范围越小越好。

建议：

• 只授权当前命令。
• 只授权当前目录。
• 只授权必要域名。
• 避免给删除、移动、上传类操作宽权限。

高风险操作前，让 Codex 先解释它要做什么。

步骤 5：把常见沙箱策略写进项目规则

项目可以在 AGENTS.md 里写常见边界。

示例：

## 沙箱与命令

- 修改内容后运行 lint 和 build。
- 不要访问项目外目录。
- 不要联网下载非官方资源。
- 删除文件前必须等待确认。

这能让 Codex 更稳定地选择命令。

常见错误

不要把沙箱错误当成必须绕过的障碍。很多时候是任务范围不清。

不要为了跑一个命令开放整个文件系统。

不要让 Codex 在没有说明用途时访问网络。

不要把敏感文件加入可写范围。

小结

沙箱让 Codex 的文件、命令和网络访问保持可控。正确做法是先写清任务范围，遇到限制时判断必要性，再用最小授权解决真正需要的操作。