OpenAI Codex 的安全控制主要看两层：沙箱决定能不能写文件、访问网络，审批策略决定什么时候必须停下来问你。默认网络关闭，workspace-write 下还会保护 .git、.codex、.agents，并且可以用 config.toml、CLI 参数和 OTel 监控验证实际生效状态。

OpenAI Codex 审批与安全配置 #

OpenAI Codex 帮助降低代码和数据被误用的风险。这里讲的是 Codex app、IDE extension 和 CLI 的安全运行方式：沙箱、审批、网络访问，以及相关限制。

如果你在找的是用于扫描已连接 GitHub repositories 的 Codex Security，请看 Codex Security。

默认情况下，agent 的网络访问是关闭的。Codex 在本地会用操作系统强制执行的沙箱限制可接触的范围，通常只到当前 workspace；同时还有一套审批策略，控制它什么时候必须先停下来问你。

如果你想先理解 Codex app、IDE extension 和 CLI 里沙箱是怎么工作的，可以看 sandboxing。如果你需要更完整的企业安全说明，可以看 Codex security white paper。

Sandbox 和审批怎么配合 #

Codex 的安全控制来自两层，它们一起工作：

• Sandbox mode：Codex 在执行模型生成的命令时，技术上能做什么，例如能写到哪里、能不能连网络。
• Approval policy：Codex 在执行某个动作前，什么时候必须先请求你确认，例如离开 sandbox、使用网络、或运行不在信任范围内的命令。

Codex 会根据运行位置使用不同的 sandbox mode：

• Codex cloud：运行在 OpenAI 管理的隔离容器里，不能访问你的主机系统或无关数据。它使用两阶段运行模型：setup 在 agent phase 之前执行，可以联网安装指定依赖；然后 agent phase 默认离线运行，除非你为该环境启用 internet access。为 cloud environment 配置的 secrets 只会在 setup 阶段可用，agent phase 开始前会移除。
• Codex CLI / IDE extension：由操作系统级机制强制执行 sandbox policy。默认不允许网络访问，写权限也只限于当前 workspace。你可以根据风险偏好配置 sandbox、approval policy 和 network settings。

在 Auto preset 中，例如 --sandbox workspace-write --ask-for-approval on-request，Codex 可以自动读取文件、修改文件，并在 working directory 里运行命令。

如果要修改 workspace 之外的文件，或者运行需要网络访问的命令，Codex 会先请求 approval。若你只想聊天或先做规划，不想产生任何改动，可以用 /permissions 切到 read-only。

Codex 也可能对有副作用的 app（connector）tool call 请求 approval，即使它不是 shell command 或文件修改。带有 destructive annotation 的 app/MCP tool call 一定需要 approval，哪怕它同时带有其他提示，比如 read-only hints。

网络访问 #

Codex cloud 的完整 internet access 或 domain allow list 配置，参考 agent internet access。

对于 Codex app、CLI 或 IDE Extension，默认的 workspace-write sandbox mode 会保持网络关闭，除非你在配置里显式开启：

[sandbox_workspace_write]
network_access = true

网络隔离 #

网络访问通过 destination rules 控制，这些规则会作用到命令启动的脚本、程序和子进程。即使已经开启了命令网络访问，也可以再打开 network_proxy feature，把流量限制到你配置的网络 policy。

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

如果只是一次性的 CLI 会话，可以在只需要开关时用 boolean 简写；如果还要设置 policy 选项，就用 table 形式：

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

这个 feature 只会改变“已开启网络访问后如何执行”，不会单独赋予网络访问权限。是否允许命令联网，仍然由 workspace-write 配置里的 sandbox_workspace_write.network_access 决定：

• 网络关闭 + network_proxy 开启：网络仍然关闭，这个 feature 不起作用。
• 网络开启 + network_proxy 关闭：网络开启，且可以直接访问外部网络，没有额外限制。
• 网络开启 + network_proxy 开启：网络开启，但出站流量会受你配置的 network policy 约束。

管理员管理的 experimental_network 要求与用户侧 feature toggle 是分开的。管理员可以在不使用 features.network_proxy 的情况下配置并启动 sandboxed networking，但如果当前 sandbox 本身把网络关掉，它也不会替你打开网络访问。管理员侧 requirements.toml 的形状请看 Managed configuration。

Network policy #

Domain rules 采用 allowlist-first 规则：

• 精确主机名只匹配自己。
• *.example.com 只匹配子域名，例如 api.example.com，不匹配 example.com 本身。
• **.example.com 同时匹配根域和子域名。
• 全局 * allow rule 会匹配所有未被 deny 的 public host。* 范围很大，应该尽量用更小范围的规则。
• deny 永远优先于 allow，而全局 * 只允许用于 allow rules。

Local 和 private destinations #

默认情况下，allow_local_binding = false 会阻止 loopback、link-local 和 private destinations：

• 需要单个本地目标时：添加一个精确的 local IP literal 或 localhost allow rule。
• 需要更宽泛的本地/私有访问时：只有在你明确要放宽边界时才设置 allow_local_binding = true。
• wildcard rules 不算显式的 local exception。
• 如果 hostname 解析到 local/private IP，即使它命中 allowlist 也仍然会被阻止。

DNS rebinding protections #

在允许某个 hostname 之前，Codex 会尽最大努力做 DNS 和 IP classification check：

• 解析失败或超时会被阻止。
• 解析到非 public address 的 hostname 会被阻止。
• 这个检查可以降低 DNS rebinding 风险，但不能完全消除。想彻底防止 rebinding，需要在 transport layer 里锁定解析出的 IP。

如果 hostile DNS 也在威胁范围内，还要在更低一层加 egress controls。

Dangerous settings #

下面两个设置会故意扩大 trust boundary：

• dangerously_allow_non_loopback_proxy = true 可能让 proxy listener 暴露到 loopback 之外。
• dangerously_allow_all_unix_sockets = true 会绕过 Unix socket allowlist。

只应在高度受控的环境里使用它们。启用 Unix socket proxying 时，即使请求了 non-loopback binding，listener 也会保持 loopback-only，因此 sandboxed networking 不会变成通向本地 daemon 的远程桥梁。

network_proxy 默认关闭。启用后：

你也可以在不开放命令完整网络访问的情况下，单独控制 web search tool。Codex 默认使用 web search cache 来取结果。这个 cache 是 OpenAI 维护的 web results index，所以 cached mode 返回的是预索引结果，不会实时抓取页面。这样能降低从任意 live content 里遇到 prompt injection 的风险，但你仍然应该把 web results 当成不可信内容处理。如果你使用 --yolo 或其他 full access sandbox setting，web search 默认会切到 live results。用 --search 或设置 web_search = "live" 可以允许 live browsing；设为 "disabled" 可以关闭这个工具：

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

启用 network access 或 web search 时要小心。prompt injection 可能诱导 agent 去抓取并执行不可信指令。

默认值和推荐做法 #

• 启动时，Codex 会检测文件夹是否受版本控制，并给出推荐：
  • 受版本控制的文件夹：Auto（workspace write + on-request approvals）
  • 不受版本控制的文件夹：read-only
• 根据你的安装方式，Codex 也可能先以 read-only 启动，直到你显式信任 working directory，例如通过 onboarding prompt 或 /permissions。
• workspace 包含当前目录和像 /tmp 这样的临时目录。用 /status 命令查看哪些目录在 workspace 里。
• 要接受默认设置，直接运行 codex。
• 你也可以显式指定：
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

可写根目录里的受保护路径 #

在默认的 workspace-write sandbox policy 下，可写根目录仍然包含受保护路径：

• <writable_root>/.git 无论是目录还是文件，都会被保护为只读。
• 如果 <writable_root>/.git 是 pointer file（gitdir: ...），解析后的 Git directory path 也会被保护为只读。
• <writable_root>/.agents 如果存在且是目录，会被保护为只读。
• <writable_root>/.codex 如果存在且是目录，会被保护为只读。
• 这种保护是递归的，所以这些路径下面的所有内容都是只读。

不显示 approval prompts 运行 #

你可以用 --ask-for-approval never 或 -a never 关闭 approval prompts。

这个选项适用于所有 --sandbox mode，所以你仍然可以控制 Codex 的自动化程度。Codex 会在你设定的约束内尽力执行。

如果你希望 Codex 在没有 approval prompts 的情况下读取文件、修改文件并运行带网络访问的命令，可以使用 --sandbox danger-full-access（或者 --dangerously-bypass-approvals-and-sandbox flag）。使用前要格外小心。

如果你想要介于两者之间的方案，approval_policy = { granular = { ... } } 允许你保留某些 approval prompt categories 为交互式，同时自动拒绝其他类别。granular policy 覆盖 sandbox approvals、execpolicy-rule prompts、MCP prompts、request_permissions prompts 和 skill-script approvals。

Automatic approval reviews #

默认情况下，approval requests 会直接路由给你：

approvals_reviewer = "user"

当 approvals 是交互式时，automatic approval reviews 才会生效，例如 approval_policy = "on-request" 或 granular approval policy。把 approvals_reviewer 设为 auto_review，可以让符合条件的 approval requests 先经过 reviewer agent，再由 Codex 执行：

approval_policy = "on-request"
approvals_reviewer = "auto_review"

完整的 reviewer 生命周期、触发条件、配置优先级和失败行为，请看 Auto-review。

reviewer 只会评估那些本来就需要 approval 的动作，例如 sandbox escalation、被阻止的 network request、request_permissions prompts，或者带副作用的 app 和 MCP tool call。仍然留在 sandbox 内的动作不会额外走一层 review。

reviewer policy 会检查 data exfiltration、credential probing、persistent security weakening 和 destructive actions。低风险和中风险动作在 policy 允许时可以继续执行。policy 会拒绝 critical-risk actions。high-risk actions 需要足够的 user authorization，且不能命中任何 deny rule。prompt-build、review-session 和 parse failures 会 fail closed。timeout 会单独返回，但动作仍不会执行。

默认 reviewer policy 在开源 Codex repository 中。企业可以用 managed requirements 里的 guardian_policy_config 替换其中的 tenant-specific section。也支持本地的 [auto_review].policy 文本，但 managed requirements 优先级更高。配置细节见 Managed configuration。

在 Codex app 里，这些 review 会显示为 automatic review items，状态可能是 Reviewing、Approved、Denied、Aborted 或 Timed out，也可能带有 risk level 和 user-authorization assessment。

Automatic review 会增加额外的 model calls，所以也会增加 Codex usage。管理员可以用 allowed_approvals_reviewers 限制它。

常见沙箱和审批组合 #

非交互式运行时，用 codex exec --sandbox workspace-write。旧的 codex exec --full-auto 仍然保留为兼容路径，但已经弃用，运行时会打印 warning。

在 --ask-for-approval untrusted 下，Codex 只会自动执行已知安全的只读操作。可能改变状态或触发外部执行路径的命令，例如破坏性的 Git 操作，或者 Git 输出/config-override flags，都需要 approval。

config.toml 里的配置 #

更完整的配置流程请看 Config basics、Advanced Config 和 Configuration Reference。

# 总是询问 approval
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: 禁止 shell-based tools 使用 login shells

# 可选：在 workspace-write 模式下允许网络
[sandbox_workspace_write]
network_access = true

# 可选：细粒度审批策略
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

你也可以把 preset 保存成 profile，然后用 codex --profile <name> 选择：

[profiles.full_auto]
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

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

本地测试 sandbox #

想看某条命令在 Codex sandbox 里会发生什么，可以用这些 Codex CLI 命令：

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

sandbox 命令也可以写成 codex debug，平台 helper 还有别名，例如 codex sandbox seatbelt 和 codex sandbox landlock。

OS-level sandbox #

Codex 会根据操作系统用不同方式强制执行 sandbox：

• macOS 使用 Seatbelt policies，并通过 sandbox-exec 运行命令，使用的 profile（-p）会对应你选的 --sandbox mode。若受限读访问启用了 platform defaults，Codex 会附加一组经过筛选的 macOS platform policy，而不是宽泛地放行 /System，这样可以保留常见工具兼容性。
• Linux 默认使用 bwrap 加 seccomp。
• Windows 在 Windows Subsystem for Linux 2 (WSL2) 中运行时使用 Linux sandbox implementation。WSL1 支持到 Codex 0.114 为止；从 0.115 开始，Linux sandbox 迁移到 bwrap，所以 WSL1 不再受支持。原生 Windows 运行时，Codex 使用 Windows sandbox 实现。

如果你在 Windows 上使用 Codex IDE extension，它可以直接支持 WSL2。可以在 VS Code settings 里设置下面的选项，让 agent 在可用时始终进入 WSL2：

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

这样即使主机系统是 Windows，IDE extension 也会继承 Linux sandbox semantics，命令、审批和文件系统访问都按 Linux 方式处理。更多内容看 Windows setup guide。

如果在原生 Windows 上运行，请在 config.toml 里配置 native sandbox mode：

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

细节见 Windows setup guide。

如果你在容器化 Linux 环境里运行，比如 Docker，而主机或容器配置阻止了 Codex 需要的 namespace、setuid bwrap 或 seccomp 操作，sandbox 可能不会工作。

这种情况下，先让 Docker 提供你需要的隔离，然后在容器内运行 codex --sandbox danger-full-access（或者 --dangerously-bypass-approvals-and-sandbox flag）。

在 Dev Containers 里运行 Codex #

如果你的主机不能直接运行 Linux sandbox，或者组织已经标准化到 containerized development，可以把 Codex 放进 Dev Containers，让 Docker 作为外层隔离边界。这适用于 Visual Studio Code Dev Containers 和兼容工具。

可以参考 Codex secure devcontainer example 作为实现样例。这个示例安装了 Codex、常用开发工具、bubblewrap，以及基于 firewall 的出站控制。

Devcontainers 提供了较强保护，但不能防住所有攻击。如果你在容器内用 --sandbox danger-full-access 或 --dangerously-bypass-approvals-and-sandbox 运行 Codex，恶意项目可以窃取 devcontainer 里可访问的任何内容，包括 Codex credentials。只有在可信 repositories 里这样做，并像其他提权环境一样监控 Codex activity。

参考实现包含：

• 基于 Ubuntu 24.04 的 base image，已安装 Codex 和常用开发工具；
• 基于 allowlist 的出站 firewall profile；
• 用于在 container 中重新打开 workspace 的 VS Code settings 和 extension recommendations；
• 用于保存命令历史和 Codex configuration 的持久化挂载；
• bubblewrap，这样在容器提供所需 capabilities 时，Codex 仍然可以使用自己的 Linux sandbox。

尝试方法：

1. 安装 Visual Studio Code 和 Dev Containers extension。
2. 把 Codex 示例 .devcontainer 配置复制到你的 repository，或者直接从 Codex repository 开始。
3. 在 VS Code 里运行 Dev Containers: Open Folder in Container…，选择 .devcontainer/devcontainer.secure.json。
4. 容器启动后，打开 terminal 并运行 codex。

你也可以从 CLI 启动容器：

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

这个示例主要由三部分组成：

• .devcontainer/devcontainer.secure.json：控制容器设置、capabilities、mounts、environment variables 和 VS Code extensions。
• .devcontainer/Dockerfile.secure：定义 Ubuntu base image 和安装的工具。
• .devcontainer/init-firewall.sh：应用出站网络 policy。

参考 firewall 只是起点。如果你依赖 domain allowlisting 做隔离，需要实现适合你环境的 DNS rebinding 和 DNS refresh protections，例如基于 TTL 的 refresh，或 DNS-aware firewall。

在容器内部，选择下面两种模式之一：

• 如果 Dev Container profile 提供了 bwrap 创建内层 sandbox 所需的 capabilities，就保留 Codex 的 Linux sandbox。
• 如果容器本身就是你要的安全边界，就在容器里用 --sandbox danger-full-access 运行 Codex，这样 Codex 就不会再尝试创建第二层 sandbox。

版本控制 #

Codex 最适合配合 version control workflow 使用：

• 在 feature branch 上工作，在委托任务前保持 git status 干净，这样 Codex 产生的 patch 更容易隔离和回滚。
• 优先使用 patch-based workflow，例如 git diff / git apply，不要直接编辑 tracked files。频繁 commit，方便小步回退。
• 把 Codex 的建议当作普通 PR 来处理：做 targeted verification、review diffs，并把决策记录在 commit messages 里，方便 audit。

监控和 telemetry #

Codex 支持通过 OpenTelemetry（OTel）做 opt-in monitoring，方便团队审计使用情况、排查问题、满足合规要求，同时不削弱本地安全默认值。Telemetry 默认关闭，需要在配置里显式开启。

概览 #

• 默认关闭 OTel export，以保持本地运行自包含。
• 启用后，Codex 会发送结构化日志事件，覆盖 conversations、API requests、SSE/WebSocket stream activity、user prompts（默认脱敏）、tool approval decisions 和 tool results。
• 导出事件会带上 service.name（originator）、CLI version 和 environment label，方便区分 dev/staging/prod 流量。

启用 OTel（opt-in） #

在 Codex 配置里添加 [otel] block，选择 exporter，并决定是否记录 prompt text。

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" 代表 instrumentation 仍然存在，但不会把数据发送到任何地方。
• 如果要发送到你自己的 collector，可以选下面两种之一：

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex 会批量发送事件，并在 shutdown 时 flush。Codex 只导出它自己的 OTel module 产生的 telemetry。

事件类别 #

典型事件包括：

• codex.conversation_starts（model、reasoning settings、sandbox/approval policy）
• codex.api_request（attempt、status/success、duration 和 error details）
• codex.sse_event（stream event kind、success/failure、duration，以及 response.completed 时的 token counts）
• codex.websocket_request 和 codex.websocket_event（request duration，加上每条消息的 kind/success/error）
• codex.user_prompt（length；内容默认脱敏，除非显式开启）
• codex.tool_decision（approved/denied，source：configuration vs. user）
• codex.tool_result（duration、success、output snippet）

关联的 OTel metrics（counter 加 duration histogram pair）包括 codex.api_request、codex.sse_event、codex.websocket.request、codex.websocket.event 和 codex.tool.call（以及对应的 .duration_ms instruments）。

完整事件目录和配置参考见 Codex configuration documentation on GitHub。

安全和隐私建议 #

• 保持 log_user_prompt = false，除非 policy 明确允许保存 prompt contents。prompt 可能包含 source code 和敏感数据。
• telemetry 只发到你控制的 collector；保留期限和访问控制要和你的合规要求一致。
• 把 tool arguments 和 outputs 都当成敏感数据。尽量在 collector 或 SIEM 侧做 redaction。
• 如果不希望 Codex 把 session transcripts 存到 CODEX_HOME，请检查本地数据保留设置，例如 history.persistence / history.max_bytes。相关内容见 Advanced Config 和 Configuration Reference。
• 如果你把 CLI 的网络访问关掉了，OTel export 也无法连到 collector。要导出数据，需要在 workspace-write mode 下为 OTel endpoint 允许网络访问，或者在 Codex cloud 里导出并把 collector domain 加到 approved list。
• 定期检查事件，确认没有意外的 approval/sandbox 变更或工具执行。

OTel 是可选能力，只是补充上面的 sandbox 和 approval protections，不会替代它们。

Managed configuration #

Enterprise admins 可以在 Managed configuration 里为 workspace 配置 Codex security settings。具体 setup 和 policy 细节请看那一页。

常见问题 #

OpenAI Codex 默认允许联网吗 #

不允许。默认情况下，agent 的网络访问是关闭的；在本地的 workspace-write 模式里也需要显式开启 sandbox_workspace_write.network_access = true。如果再启用 network_proxy，才能把流量限制到你配置的 domain rules。

Codex 为什么会要求审批才能改 workspace 外的文件 #

因为默认 sandbox 只允许在当前 workspace 内自动工作。要修改 workspace 外的文件，或者运行需要网络访问的命令，Codex 会先请求 approval；有副作用的 app/MCP tool call 也可能触发 approval。

.git、.codex、.agents 为什么还是只读 #

在默认 workspace-write sandbox policy 下，这些路径被额外保护为只读，而且保护是递归的。即使根目录可写，Codex 也不能修改这些受保护路径里的内容。