Codex 在本地运行时通过两层机制保护你的系统：沙箱限制 Agent "能做什么"（文件权限和网络访问），审批策略控制 Agent "什么时候必须停下来问你"。默认配置下 Codex 只能读写当前工作目录，网络关闭，.git/.codex/.agents 目录受到额外保护。本文覆盖所有配置选项、常用组合、OTel 监控，以及各平台的实现差异。

Codex Agent 审批与安全

Codex 的本地安全控制围绕两个层次：沙箱模式（技术边界）和审批策略（决策节点）。

这页讲的是 Codex Agent 的运行安全。如果你在找 Codex Security 的代码漏洞扫描产品，参考 Codex Security。

---

两层安全模型

层次	作用	配置键
沙箱模式	定义 Agent 的技术访问边界（哪些目录可写、能否访问网络）	sandbox_mode
审批策略	决定 Agent 何时必须停下来征求你的意见	approval_policy

默认行为：版本控制仓库里默认 workspace-write + on-request；非版本控制目录默认 read-only。

---

沙箱模式详解

read-only

只读咨询模式。Codex 可以读文件、回答问题，但不能自动修改文件或执行命令。

workspace-write（默认）

日常开发模式。Codex 可以读写工作目录、运行常见本地命令。网络访问默认关闭。

保护路径（即使在 workspace-write 下也是只读）：

• <workspace>/.git（含 gitdir 链接指向的实际目录）
• <workspace>/.agents
• <workspace>/.codex

danger-full-access

完全无限制，包括网络。仅在可信容器环境里使用。

---

审批策略详解

策略	含义
on-request	沙箱内自动执行，超出边界时暂停询问
untrusted	只自动执行已知安全的只读操作，其他命令（包括可能变更状态的 Git 操作）都要确认
never	从不询问（配合沙箱保护使用）

---

常用组合

场景	命令
日常开发（推荐）	codex 或 codex --full-auto
只读咨询	codex --sandbox read-only --ask-for-approval on-request
CI 只读脚本	codex --sandbox read-only --ask-for-approval never
需要确认所有命令	codex --sandbox workspace-write --ask-for-approval untrusted
危险完全访问	codex --dangerously-bypass-approvals-and-sandbox（--yolo）

--full-auto = --sandbox workspace-write --ask-for-approval on-request

---

网络访问控制

本地运行时，workspace-write 模式下网络默认关闭。开启方式：

[sandbox_workspace_write]
network_access = true

Web Search 独立控制（不需要开全局网络访问）：

web_search = "cached"    # 默认：OpenAI 预索引的结果（减少 prompt injection）
# web_search = "live"    # 实时获取，同 --search 标志
# web_search = "disabled" # 关闭 Web Search

使用 --yolo 时 Web Search 自动切换为 live 模式。注意提示注入（prompt injection）风险。

Codex Cloud 的网络控制参考：网络访问控制

---

config.toml 配置

sandbox_mode    = "workspace-write"
approval_policy = "on-request"

# 开启网络访问
[sandbox_workspace_write]
network_access = true

# 保存为 Profile
[profiles.full_auto]
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[profiles.readonly_quiet]
approval_policy = "never"
sandbox_mode    = "read-only"

使用 Profile：codex --profile full_auto

细粒度审批策略

approval_policy = { granular = {
  sandbox_approval = true,      # 沙箱越界时询问
  rules = true,                 # Rules 规则触发时询问
  mcp_elicitations = true,      # MCP 工具副作用时询问
  request_permissions = false,  # 权限请求时不询问
  skill_approval = false        # Skill 脚本时不询问
} }

---

测试沙箱行为

# macOS
codex sandbox macos --full-auto [命令]
codex sandbox macos --log-denials [命令]   # 记录所有被拒绝的操作

# Linux
codex sandbox linux --full-auto [命令]

---

OTel 监控（可选，合规用途）

Codex 支持通过 OpenTelemetry 导出结构化日志，默认关闭。适合企业合规审计：

[otel]
environment = "prod"
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}
log_user_prompt = false  # 默认脱敏，除非策略明确允许

主要事件类型：

• codex.conversation_starts（会话开始，含模型和沙箱配置）
• codex.api_request / codex.sse_event（API 调用统计）
• codex.user_prompt（长度，内容默认脱敏）
• codex.tool_decision（批准/拒绝，来源：配置 or 用户）
• codex.tool_result（执行时间、成功/失败、输出片段）

安全提示：保持 log_user_prompt = false；只发送到你控制的收集器；工具参数和输出要视为敏感数据。

---

平台实现

平台	沙箱实现
macOS	Seatbelt（sandbox-exec），内置无需安装
Linux / WSL2	bubblewrap（bwrap）+ seccomp
Windows 原生	Windows Sandbox
Windows WSL2	Linux 沙箱实现（WSL1 从 0.115 版起不再支持）

IDE 扩展在 Windows 上推荐 WSL2 模式：

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Docker 容器里如果 Landlock/seccomp 不可用，让 Docker 提供隔离，然后在容器内用 --sandbox danger-full-access。

---

版本控制工作流建议

• 在功能分支上工作，保持 git status 干净后再委托任务给 Codex
• 用 git diff 查看 Codex 的改动，用 git checkout 回滚不满意的修改
• 把 Codex 的改动当作 PR 对待：运行验证、Review diff、在 commit 消息里记录决策

---

常见问题

Q: --full-auto 和 --yolo 有什么区别？

A: --full-auto = workspace-write 沙箱 + on-request 审批，Codex 在工作目录里自由工作，需要超出边界时才问你。--yolo = 完全绕过沙箱和审批，无任何限制——不推荐在本机日常使用，只在隔离容器环境里考虑使用。

Q: 我在 Docker 容器里跑 Codex，沙箱为什么不工作？

A: 沙箱依赖 Linux 的 Landlock 和 seccomp 内核特性，部分 Docker 配置不启用这些。解决方法：让 Docker 提供外层隔离，在容器内用 --sandbox danger-full-access 跳过 Codex 的沙箱检查。

Q: Codex 能修改 .git 目录里的内容吗？

A: 不能。在 workspace-write 模式下，.git、.agents、.codex 目录被硬编码保护为只读，Codex 无法修改这些路径。