代码语言

知识点思维导图

24 个知识节点

参考资料

Codex（05） - 权限、沙盒与安全边界

读完后，你应能完成以下任务：

绘制“Codex（05） - 权限、沙盒与安全边界 / 概念解释”的关键对象与数据流，解释“注意：不同环境可能有额外外层限制。”，并用源码位置、日志或 Trace 标注证据。

为“Codex（05） - 权限、沙盒与安全边界 / 使用示例”设计正常与异常输入，验证“适合你只想要报告，不希望它动代码。”，输出首个偏差位置与回归测试结果。

实现“Codex（05） - 权限、沙盒与安全边界 / 常规开发”的最小代码或配置，检验“Codex 可以在项目里改文件，遇到需要更高权限的操作再问你。”，输出命令、结果与 Diff，并说明不适用边界。

Codex 能运行命令、读写文件，所以安全边界非常重要。你需要理解两个概念：sandbox 和 approval。

sandbox 决定 Codex 能在什么范围内执行命令。
approval 决定哪些操作需要先问你。

这很像浏览器权限：页面能不能访问摄像头是一回事，访问前要不要弹窗确认是另一回事。

一、概念解释

常见沙盒模式：

模式	含义	适合场景
`read-only`	只读，不能写文件	解释、审查、风险评估
`workspace-write`	可写当前工作区	常规开发任务
`danger-full-access`	基本不限制文件访问	你明确知道风险的本地任务

常见审批策略：

策略	含义
`untrusted`	只允许可信命令直接跑，其他询问
`on-request`	Codex 判断何时请求审批
`never`	不询问，失败就返回给 Codex

注意：不同环境可能有额外外层限制。不要把“CLI 参数允许”理解成“所有环境都一定能执行”。

二、使用示例

2.1 只读审查

codex exec \
  -C /path/to/project \
  --sandbox read-only \
  --ask-for-approval never \
  "请审查当前项目的测试覆盖风险，不要修改文件"

适合你只想要报告，不希望它动代码。

2.2 常规开发

codex \
  -C /path/to/project \
  --sandbox workspace-write \
  --ask-for-approval on-request \
  "帮我修复用户列表分页 bug，并运行相关测试"

Codex 可以在项目里改文件，遇到需要更高权限的操作再问你。

2.3 高风险模式

codex \
  -C /path/to/project \
  --sandbox danger-full-access \
  --ask-for-approval never

这个组合风险很高，只适合外部已经隔离好的环境，比如临时容器、一次性工作区。

三、什么操作要特别小心

删除文件或目录。
改数据库迁移。
修改生产配置。
操作云资源。
写入全局配置。
提交、推送、发布。
处理密钥、cookie、token。

这类任务要明确写边界，并尽量让 Codex 先给计划。

四、常见错误

4.1 错误 1：为了省事长期使用最高权限

danger-full-access 很方便，但它会让误操作的影响范围变大。日常开发优先使用 workspace-write。

4.2 错误 2：把密钥贴给 Codex

不要把真实 token、cookie、私钥写进提示词或文件。需要调试鉴权时，用脱敏样例。

Authorization: Bearer <redacted-token>

4.3 错误 3：让 Codex 直接操作生产环境

比如：

帮我连上生产数据库删掉异常数据。

更安全的流程是：

让 Codex 分析 SQL。
在只读环境验证查询。
人工确认变更脚本。
走团队发布流程。

五、最佳实践

默认从最小权限开始。
高风险任务先让 Codex 输出计划，不直接执行。
把禁止事项写进提示词和 AGENTS.md。
对外部系统操作优先通过 MCP 或内部工具封装权限，而不是让 Codex 拿裸密钥。
执行前后检查 git diff，确认没有无关改动。

六、本章小结

安全不是“不让 Codex 做事”，而是给它合适的活动范围。低风险任务放开一点，高风险任务收紧一点，才是长期可用的方式。

七、动手实践：05 sandbox and approval

这个 demo 用来练习不同权限组合下该如何给 Codex 任务。

7.1 目录内容

safe-review-prompt.md：只读审查任务。
write-task-prompt.md：允许修改工作区的任务。
notes.md：示例文件。

7.2 使用方式

只读审查：

codex exec --sandbox read-only --ask-for-approval never - < safe-review-prompt.md

允许修改当前工作区：

codex --sandbox workspace-write --ask-for-approval on-request - < write-task-prompt.md

7.3 练习目标

理解只读任务和写任务的区别。
给高风险操作设置明确边界。
学会在提示词里写禁止事项。

7.4 配套实践材料

以下材料已并入正文，便于阅读时直接对照和练习。

notes.md

# Codex 使用心得

Codex 很适合处理明确的小任务，也适合整理文档，但是如果任务很模糊它就会猜。使用的时候最好说清楚目标、范围、约束和验收。对于危险操作要先让它给计划。AGENTS.md 可以放长期规则。不要把密钥贴进去。CLI 适合自动化，交互界面适合探索。

safe-review-prompt.md

请审查 `notes.md`，不要修改文件。

重点：
- 是否有明显事实矛盾。
- 是否有结构混乱。
- 是否有可以拆成清单的内容。

输出：
- 只输出发现和建议。
- 不要改文件。

write-task-prompt.md

请整理 `notes.md`。

允许：
- 调整标题层级。
- 拆分过长段落。
- 增加清单。

禁止：
- 不要删除原始观点。
- 不要新增外部事实。
- 不要修改本目录以外的文件。

验收：
- 修改后说明你改了什么。

八、总结

概念解释：| 模式 | 含义 | 适合场景 |
使用示例：适合你只想要报告，不希望它动代码。
什么操作要特别小心：这类任务要明确写边界，并尽量让 Codex 先给计划。
常见错误：让 Codex 分析 SQL。 -> 在只读环境验证查询。 -> 人工确认变更脚本。 -> 走团队发布流程。
最佳实践：高风险任务先让 Codex 输出计划，不直接执行。
高风险模式：这个组合风险很高，只适合外部已经隔离好的环境，比如临时容器、一次性工作区。