权限与安全

是什么

它是什么#

sandbox、approval、network、auth 和 secret 管理共同构成安全边界。默认应该用最小权限：能只读就不写，能限定工作区就不开放 full access。

Desktop 常见选择

Codex Desktop 常见权限选择#

下面四类是常见 UI 入口，但实际菜单取决于本地配置和组织策略；workspace-write、read-only、on-request 等是底层 sandbox / approval 配置名，常见于 CLI 或 config.toml，不要把它们当成额外的 Desktop 固定模式。

CLI 高风险别名（不是 Desktop 模式）：--dangerously-bypass-approvals-and-sandbox 是 CLI 的高风险别名，不是 Desktop 的第五种权限模式；它会绕过审批和沙箱保护，仅应在外部已经强隔离的受控环境中使用。

实操建议：第一次先选 Ask for approval，明确工作区与验证方式；确认任务和仓库可信后再考虑 Approve for me。只有确有必要且已有外部隔离时才使用 Full access 或 CLI 绕过保护。

何时使用

什么时候批准#

• 批准安装依赖、访问 GitHub API、启动本地服务、验证线上页面，并且命令范围清楚。
• 拒绝理由不清、路径过宽、可能触碰 secret、命令具有破坏性，或没有必要为了当前任务执行。
• 要求说明让 Codex 说明为什么需要权限、会访问哪些路径、会改哪里、如何验证和如何停止。

示例

可复制示例#

在运行任何需要网络或写权限的命令前，
请先说明：
1. 为什么需要这个权限；
2. 会读写哪些路径；
3. 失败后如何恢复；
4. 成功后如何验证。

补充内容

补充内容#

• 桌面端权限等级从低权限到高权限理解读写边界，优先从 Ask for approval 起步。
• 审批决策矩阵快速判断哪些动作可批准、哪些动作需要追问或拒绝。
• 申请权限模板统一审批输出格式，降低误会和追问成本。
• Secret 与生产数据明确哪些文件、字段、密钥不能被读取或提及。

决策矩阵

审批决策矩阵#

审批 prompt

你可以这样要求 Codex 申请权限#

需要提升权限时，请用这个格式说明：

Action:
- 你要运行什么命令？

Reason:
- 为什么当前任务必须运行它？

Scope:
- 会访问哪些路径、网络目标或外部系统？

Risk:
- 最坏会发生什么？如何停止或恢复？

Verification:
- 成功后如何证明结果有效？

Secret 安全

Secret 和生产数据规则#

不要让 Codex 读取、复制、总结或提交 secret。即使只是“看一眼配置”，也要先确认文件是否可能包含 token、证书、cookie、数据库密码或生产数据。需要使用密钥时，优先让用户在受控环境中配置，不要把密钥写进聊天、网页或仓库。

真实实例

真实实例：CI 只读网络诊断#

任意团队仓库都可能遇到：CI 需要拉取公开依赖或查询 artifact 状态，但 token 权限必须最小化。Codex 在 Desktop 里先列出将要访问的域名和只读动作，获批后再执行。

申请权限理由：
Action: curl -fsSL https://registry.example.org/v2/.../manifests/latest
Reason: 确认 CI 使用的 base image digest 是否与 lockfile 一致
Scope: 只读 HTTPS GET，不写 registry
Risk: 无写入；失败时报告无法拉取 manifest
Verification: 返回 digest 与 lockfile 中记录一致

本项目没有该 CI 仓库的执行记录，因此标为演示场景。

真实实例

真实实例：验证 GitHub Pages 发布#

这份手册发布后，Codex 需要确认线上页面是否已经更新。这个动作需要网络访问，但不需要写外部系统，所以适合申请只读网络权限：先查 Pages 状态，再用 curl 抓取公开 HTML 中的关键标题。

申请权限理由：
Action: gh api repos/WhoJay0609/codex-usage-guide/pages
Reason: 确认 GitHub Pages 是否 built
Scope: 只读 GitHub Pages 状态
Risk: 无写入；失败时只报告无法验证
Verification: 页面返回 built，公开 HTML 包含新章节标题