Permissions & Approval

Abstract

Permission System 决定 Coding Agent 什么时候可以直接行动、什么时候必须询问用户。太严格会让 Agent 频繁打断用户，太宽松则可能带来文件破坏、命令误执行和数据泄露风险。

Codex CLI 更偏向 沙箱边界 + 显式审批 + 声明式策略
Claude Code 更偏向 工具级权限 + 多层规则 + 交互式确认

Codex：Sandbox + Approval

Codex 的权限系统可以分成两层理解：

Sandbox / Permission Profile：限制 Agent 能访问哪些文件、能否联网、能写哪些路径
Approval / Escalation：当操作超出当前权限边界时，向用户请求批准

这种设计的核心是：先把 Agent 放进明确边界内运行；当确实需要越过边界时，再让用户显式确认。

Permission Profiles

Codex 官方文档中更稳定的抽象是 permission profile。它定义 Agent 在默认情况下能做什么。

Profile	行为
`:read-only`	只能读取文件和回答问题，不能修改文件或执行高风险操作
`:workspace`	可以在当前 workspace 内读写和执行常见开发操作，越界时需要审批
`:danger-full-access`	允许更高权限操作，适合受信任环境，但风险最高

Warning

danger-full-access 适合短期、明确、受信任的任务，不适合作为默认模式。Coding Agent 的错误命令、错误路径或错误假设都会在高权限模式下被放大。

Approval Requests

当工具调用涉及敏感操作时，Codex 会把操作包装成可审查的请求，让用户决定是否允许。

常见请求类型可以概括为：

Shell Command：执行 shell 命令
File Mutation：通过 patch 或编辑工具修改文件
Network Access：访问外部网络
MCP Tool Call：调用外部 MCP 工具
Permission Amendment：请求扩大当前 session 的权限边界

Approval Flow

工具准备执行敏感操作
    ↓
判断当前权限是否覆盖该操作
    ↓
若需要审批，生成权限请求
    ↓
向用户展示操作内容、原因和影响范围
    ↓
用户批准或拒绝
    ↓
记录决策并继续 / 中止执行
    ↓
必要时更新本次 session 的权限策略

Execution Policies

Codex 还可以使用更细粒度的执行策略来减少重复确认。例如某些命令前缀、文件路径或网络访问目标可以被声明为允许，从而让相似操作在后续自动通过。

典型策略包括：

允许特定命令前缀，例如 npm test、cargo test
允许写入特定路径，例如 /tmp/build
限制或禁止访问外部网络
允许模型通过 request_permissions 类工具说明为什么需要额外权限

关键设计

Codex 的权限模型更接近系统策略：规则写下来，由运行时匹配。模型可以提出“我需要这个权限”，但是否授权由用户和策略系统决定。

Prompt Integration

不同权限模式会影响系统提示词和模型行为。只读模式下，模型会被要求不要修改文件；workspace 模式下，模型可以在工作区内行动；高权限模式下，模型会获得更大行动空间，同时也更依赖用户对任务环境的信任。

只读权限
    → 读取、分析、解释，不主动修改

工作区权限
    → 可以编辑当前项目，越界时请求确认

高权限模式
    → 更少阻拦，但需要用户承担更高风险

代码位置

Permissions docs：OpenAI Codex permissions
Tool orchestration：codex-rs/core/src/tools/orchestrator.rs
Permission request tool：codex-rs/core/src/tools/handlers/request_permissions.rs
Execution policy crate：codex-rs/execpolicy/

Claude Code：Multi-Layer Permission System

Claude Code 的权限系统更强调工具级控制：每个工具调用都可以根据工具类型、输入参数、项目配置、用户设置和组织策略判断是否允许。

Permission Modes

Claude Code 官方文档中列出了多种 permission mode：

Mode	行为
`default`	对每个新操作请求权限
`acceptEdits`	自动接受文件编辑，其它操作仍需确认
`plan`	计划模式，只允许分析和规划，不直接修改
`auto`	根据安全规则自动允许或拒绝，减少确认弹窗
`dontAsk`	拒绝需要确认的操作，接近只读体验
`bypassPermissions`	跳过权限检查，风险最高

Warning

bypassPermissions 类模式适合受控环境中的短期任务，不适合处理不可信代码库、生产凭证或高风险命令。

Permission Rules

Claude Code 的规则可以表达三类行为：allow、deny、ask。规则可以来自用户设置、项目设置、命令行参数或组织策略。

权限请求
    ↓
加载组织 / 用户 / 项目 / 会话规则
    ↓
按优先级匹配 allow、deny、ask
    ↓
允许、拒绝或弹出确认

规则通常围绕工具名和输入模式展开，例如：

Bash(npm:*)          → 允许 npm 相关命令
Edit(.claude/**)     → 允许编辑 Claude Code 配置
Bash(rm:*)           → 拒绝高风险删除命令

关键设计

Claude Code 的权限规则更贴近产品配置：用户可以通过设置文件、项目配置或交互式弹窗逐步调整 Agent 能做什么。

Permission Dialog

在默认模式下，遇到风险操作时用户会看到交互式确认。确认信息通常需要让用户理解三件事：

哪个工具要执行
输入参数是什么
这次操作可能产生什么影响

┌─ Permission Request ───────────────────────┐
│ Tool: Bash                                  │
│ Command: npm install express                │
│                                             │
│ [Allow]  [Allow Always]  [Deny]             │
└─────────────────────────────────────────────┘

常见选项包括：

Allow：只允许本次操作
Allow Always：为类似操作添加持久规则
Deny：拒绝本次操作
Deny Always：为类似操作添加拒绝规则

Enterprise Controls

Claude Code 面向企业场景时，权限系统还需要支持组织级控制：

通过组织策略统一管理允许或禁止的工具行为
对高风险模式进行限制
在项目或用户配置之外加入更高优先级的规则
记录被拒绝或被批准的敏感操作，方便审计和治理

对比

维度	Codex CLI	Claude Code
核心思路	沙箱边界 + 审批升级	工具级权限 + 多层规则
默认控制点	文件系统、网络、命令执行边界	每个工具调用及其输入参数
自动允许	通过 permission profile / execution policy 匹配	通过权限模式和规则匹配
用户确认	超出权限边界时请求批准	风险工具调用时弹出确认
运行时变更	可请求扩大当前权限范围	可通过对话或设置添加规则
持久化	配置、策略、session 权限	用户 / 项目 / 组织 settings
企业治理	更偏配置与执行策略	更偏组织策略、settings 和工具规则

Key Design Difference

Codex 更像是在操作系统边界上做权限控制：先规定 Agent 能访问什么，再让 shell、patch、MCP 等工具在边界内工作。它强调的是 containment。

Claude Code 更像是在应用层工具系统上做权限控制：每个工具调用都可以被匹配、解释、允许、拒绝或要求用户确认。它强调的是 control at every layer。

小结

权限系统是 Coding Agent 能否被信任的关键。

Codex 的问题是：如何给模型足够行动力，同时用沙箱和策略限制破坏范围。Claude Code 的问题是：如何把每个工具调用解释清楚，并让用户或组织策略决定是否允许。

一个好的权限系统不是简单地“多问用户”或“少问用户”，而是在合适的风险边界上问对问题。