权限、沙箱与网络¶

Codex 的权限模型由三层组成：permission profile 描述允许什么，sandbox backend 执行限制，approval policy 决定什么时候需要用户或 Guardian 批准。

Permission Profile¶

codex-rs/core/src/config/permissions.rs 定义内置 profile：

Profile	语义
`:read-only`	默认只读
`:workspace-write`	workspace roots 可写，其它位置受限
`:danger-full-access`	文件系统 sandbox disabled

受信项目默认通常是 workspace profile；非受信或 Windows sandbox disabled 时更保守地使用 read-only。

用户自定义 profile 不能以 : 开头，因为这是内置 profile 的保留前缀。

ResolvedPermissionProfile¶

codex-rs/core/src/config/resolved_permission_profile.rs 把 profile 分成三种：

Legacy：只有 concrete PermissionProfile，没有 active profile id。
BuiltIn：内置 profile id、extends、concrete profile、profile workspace roots。
Named：用户命名 profile。

PermissionProfileState 用 Constrained<ResolvedPermissionProfile> 包住 resolved profile，确保 session settings update 不会绕过 requirements 约束。

文件系统权限¶

文件系统权限由 FileSystemSandboxPolicy 表示，路径可以是：

具体 path。
glob pattern。
special path：:root、:minimal、:workspace_roots、:tmpdir、:slash_tmp 等。

profile 中的 :workspace_roots 会在 session runtime 根据实际 workspace roots materialize，解决“配置是符号路径，运行时才知道项目根”的问题。

网络权限¶

profile 的 network.enabled 控制 sandbox 网络访问。网络 proxy 的配置可以来自 profile 和 feature config，但 profile 自身不会直接启动 managed proxy。apply_network_proxy_feature_config 会把 feature 层配置合入 proxy config。

工具执行时，如果 managed network 生效，ToolOrchestrator 会通过 network approval 流处理被策略拦截的访问。

Sandbox Backend¶

codex-rs/sandboxing 按平台选择实现：

macOS：seatbelt。
Linux：bubblewrap 或 landlock。
Windows：restricted token / elevated backend 等 Windows-specific override。

SandboxManager 会根据 permission profile、network policy、工具偏好和平台能力选择初次执行 sandbox。

审批与升级重试¶

工具执行的升级路径在 ToolOrchestrator：

判断 ExecApprovalRequirement。
必要时请求用户、Guardian 或 PermissionRequest hook。
在初始 sandbox 下执行。
如果 sandbox denied 且策略允许，生成 retry reason。
再次审批后无沙箱或调整 sandbox 重试。

关键细节：严格 auto-review 下，sandboxed attempt 的审批不覆盖 unsandboxed retry，必须重新 review。

可学习的设计¶

Codex 把权限控制拆成可解释的层：

profile 是声明式策略。
sandbox 是执行机制。
approval 是人或自动 reviewer 的决策。
hook 是组织或用户自定义策略。
telemetry 记录每次 sandbox outcome。