设置审批和安全边界

Codex 会帮助保护你的代码和数据，并降低误用风险。

本篇讲如何安全地操作 Codex，包括 sandboxing（沙箱）、approvals（审批）和 network access（网络访问）。

如果你要找的是 Codex Security，也就是用于扫描已连接 GitHub repositories（GitHub 仓库）的产品，请看：

https://developers.openai.com/codex/security

默认情况下，Agent 的网络访问是关闭的。在本地运行时，Codex 使用操作系统强制执行的 sandbox（沙箱），限制它能接触的内容，通常限制在当前 workspace（工作区）。同时，Codex 还使用 approval policy（审批策略），决定它什么时候必须停下来问你，才能继续行动。

关于 Codex app、IDE extension 和 CLI 中 sandboxing 的高层解释，见：

https://developers.openai.com/codex/concepts/sandboxing

更宽泛的企业安全概览，见 Codex security white paper：

https://trust.openai.com/?itemUid=382f924d-54f3-43a8-a9df-c39e6c959958&source=click

Sandbox and approvals

Codex 的安全控制由两层配合完成：

Sandbox mode（沙箱模式）：决定 Codex 在执行模型生成的命令时，技术上能做什么。例如能写哪里、能不能访问网络。
Approval policy（审批策略）：决定 Codex 在执行动作前什么时候必须问你。例如离开沙箱、使用网络、或运行受信任集合之外的命令。

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

Codex cloud：运行在 OpenAI 托管的隔离容器中，不能访问你的主机系统或无关数据。它使用两阶段 runtime model（运行时模型）：setup 阶段在 agent 阶段前运行，可以访问网络安装指定依赖；agent 阶段默认离线，除非你为环境启用 internet access。配置给 cloud environments 的 secrets 只在 setup 阶段可用，进入 agent 阶段前会被移除。
Codex CLI / IDE extension：由操作系统级机制强制执行 sandbox policies。默认包括无网络访问，以及写权限限制在 active workspace（当前工作区）。你可以按自己的风险承受能力配置 sandbox、approval policy 和网络设置。

在 Auto preset（自动预设）里，例如 --sandbox workspace-write --ask-for-approval on-request，Codex 可以自动读取文件、编辑文件，并在当前工作目录运行命令。

当 Codex 要编辑 workspace 外的文件，或运行需要网络访问的命令时，会请求审批。如果你只想聊天或规划，不希望它改动文件，可以用 /permissions 命令切换到 read-only 模式。

如果 app connector tool calls（应用连接器工具调用）声明了 side effects（副作用），即使它不是 shell 命令或文件改动，Codex 也可以触发审批。Destructive app/MCP tool calls（破坏性应用 / MCP 工具调用）只要工具声明了 destructive annotation，就总是需要审批，即便它同时声明了只读提示。

Network access

对于 Codex cloud，如果要启用完整 internet access 或 domain allow list（域名允许列表），请看 agent internet access：

https://developers.openai.com/codex/cloud/internet-access

对于 Codex app、CLI 或 IDE Extension，默认 workspace-write sandbox mode 会关闭网络访问，除非你在配置里启用：

[sandbox_workspace_write]
network_access = true

你也可以控制 web search tool（网页搜索工具），而不必给生成命令完整网络访问权限：

https://platform.openai.com/docs/guides/tools-web-search

Codex 默认使用 web search cache 获取搜索结果。这个缓存是 OpenAI 维护的网页结果索引，所以 cached mode 返回的是预索引结果，不是实时抓取页面。这可以降低任意实时网页内容带来的 prompt injection 风险，但你仍然应该把网页结果当作不可信内容。

如果你使用 --yolo 或其他 full access sandbox setting，web search 默认使用 live results。你可以使用 --search，或把 web_search 设为 "live" 来允许实时浏览；也可以设为 "disabled" 来关闭工具：

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

启用 Codex 的网络访问或 web search 时要谨慎。Prompt injection 可能诱导 Agent 获取并遵循不可信指令。

Defaults and recommendations

启动时，Codex 会检测当前文件夹是否受 version control（版本控制）管理，并给出推荐：
- 受版本控制的文件夹：Auto，也就是 workspace write + on-request approvals。
- 不受版本控制的文件夹：read-only。
根据你的设置，Codex 也可能先以 read-only 启动，直到你显式 trust 当前工作目录，例如通过 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

Protected paths in writable roots

在默认 workspace-write sandbox policy 中，即便某个 root 可写，其中仍然包含受保护路径：

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

Deny reads with filesystem profiles

Named permission profiles（命名权限档案）也可以拒绝读取精确路径或 glob patterns（通配模式）。

当 workspace 应该保持可写，但某些敏感文件，例如本地环境文件，必须保持不可读时，这很有用：

default_permissions = "workspace"

[permissions.workspace.filesystem]
":project_roots" = { "." = "write", "**/*.env" = "none" }
glob_scan_max_depth = 3

对 Codex 不应该读取的路径或 glob，使用 "none"。Sandbox policy 会为本地 macOS 和 Linux 命令执行评估 globs。

在某些平台上，glob 匹配会在 sandbox 启动前预展开。对于无界 ** pattern，可以设置 glob_scan_max_depth，或者列出显式深度，例如 *.env、*/*.env 和 */*/*.env。

Run without approval prompts

你可以用 --ask-for-approval never 或简写 -a never 关闭审批提示。

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

如果你需要 Codex 在没有审批提示的情况下读取文件、编辑文件、运行命令并访问网络，可以使用：

--sandbox danger-full-access

或者：

--dangerously-bypass-approvals-and-sandbox

这个模式风险很高，使用前必须谨慎。

折中方案是使用：

approval_policy = { granular = { ... } }

它让你保留特定审批提示类别的交互，同时自动拒绝其他类别。granular policy 覆盖 sandbox approvals、execpolicy-rule prompts、MCP prompts、request_permissions prompts 和 skill-script approvals。

Automatic approval reviews

默认情况下，审批请求会交给你：

approvals_reviewer = "user"

当 approvals 是交互式时，例如 approval_policy = "on-request" 或 granular approval policy，可以使用 automatic approval reviews（自动审批审查）。

把 approvals_reviewer 设为 auto_review 后，符合条件的审批请求会先交给 reviewer agent（审查 Agent）评估，然后 Codex 再运行请求：

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

Reviewer 只评估那些本来就需要审批的动作，例如 sandbox escalations（沙箱提权）、network requests（网络请求）、request_permissions prompts，或者有副作用的 app / MCP tool calls。仍在 sandbox 内的动作不会多出额外审查步骤。

Reviewer policy 会检查 data exfiltration（数据外泄）、credential probing（凭据探测）、persistent security weakening（持久性削弱安全）和 destructive actions（破坏性动作）。低风险和中风险动作在策略允许时可以继续。策略会拒绝 critical-risk actions（关键风险动作）。高风险动作需要足够用户授权，且不能命中拒绝规则。Timeouts、parse failures 和 review errors 都会 fail closed（失败时关闭，也就是拒绝继续）。

默认 reviewer policy 在开源 Codex 仓库中：

https://github.com/openai/codex/blob/main/codex-rs/core/src/guardian/policy.md

企业可以用 managed requirements 里的 guardian_policy_config 替换其中的 tenant-specific section（租户专属部分）。本地 [auto_review].policy 文本也支持，但 managed requirements 优先级更高。

配置细节见：

https://developers.openai.com/codex/enterprise/managed-configuration#configure-automatic-review-policy

在 Codex app 中，这些 review 会显示为 automatic review items，并带有 Reviewing、Approved、Denied、Stopped 或 Timed out 等状态。它们也可能包含被审查请求的 risk level（风险级别）。

Automatic review 会使用额外模型调用，因此可能增加 Codex 使用量。管理员可以用 allowed_approvals_reviewers 限制它。

Common sandbox and approval combinations

Intent	Flags	Effect
Auto (preset)	no flags needed or `--sandbox workspace-write --ask-for-approval on-request`	Codex 可以读取文件、编辑文件，并在 workspace 中运行命令。编辑 workspace 外文件或访问网络时需要审批。
Safe read-only browsing	`--sandbox read-only --ask-for-approval on-request`	Codex 可以读取文件并回答问题。编辑、运行命令或访问网络都需要审批。
Read-only non-interactive (CI)	`--sandbox read-only --ask-for-approval never`	Codex 只能读取文件；不会请求审批。
Automatically edit but ask for approval to run untrusted commands	`--sandbox workspace-write --ask-for-approval untrusted`	Codex 可以读取并编辑文件，但运行不受信任命令前会请求审批。
Dangerous full access	`--dangerously-bypass-approvals-and-sandbox` (alias: `--yolo`)	没有 sandbox，也没有 approvals；不推荐。

对于 non-interactive runs（非交互运行），使用：

codex exec --sandbox workspace-write

旧的 codex exec --full-auto 调用仍作为 deprecated compatibility path（已弃用兼容路径）保留，并会打印 warning。

使用 --ask-for-approval untrusted 时，Codex 只会自动运行已知安全的只读操作。会改变状态或触发外部执行路径的命令，例如破坏性 Git 操作或 Git output/config-override flags，都需要审批。

Configuration in `config.toml`

更完整的配置流程见：

Config basics：https://developers.openai.com/codex/config-basic
Advanced Config：https://developers.openai.com/codex/config-advanced#approval-policies-and-sandbox-modes
Configuration Reference：https://developers.openai.com/codex/config-reference

# Always ask for approval mode
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

你也可以把 presets（预设）保存为 profiles，然后用 codex --profile <name> 选择：

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

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

Test the sandbox locally

如果你想观察命令在 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 使用。平台 helpers 也有 aliases，例如 codex sandbox seatbelt 和 codex sandbox landlock。

OS-level sandbox

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

macOS 使用 Seatbelt policies，并通过 sandbox-exec 运行命令，使用的 profile（-p）对应你选择的 --sandbox mode。当 restricted read access 启用 platform defaults 时，Codex 会追加一套精选的 macOS platform policy，而不是宽泛允许 /System，以保持常见工具兼容性。
Linux 默认使用 bwrap 加 seccomp。
Windows 在 Windows Subsystem for Linux 2（WSL2）中运行时使用 Linux sandbox 实现。WSL1 支持到 Codex 0.114；从 0.115 开始，Linux sandbox 迁移到 bwrap，所以 WSL1 不再支持。原生运行在 Windows 上时，Codex 使用 Windows sandbox 实现。

Windows 相关文档：

WSL2：https://developers.openai.com/codex/windows#windows-subsystem-for-linux
Windows sandbox：https://developers.openai.com/codex/windows#windows-sandbox

如果你在 Windows 上使用 Codex IDE extension，它直接支持 WSL2。在 VS Code settings 中设置下面内容，可以让 agent 在可用时始终留在 WSL2 内：

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

这样即使宿主系统是 Windows，IDE extension 也会继承 Linux sandbox 的命令、审批和文件系统访问语义。更多内容见 Windows setup guide：

https://developers.openai.com/codex/windows

原生运行在 Windows 上时，在 config.toml 中配置 native sandbox mode：

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

细节见：

https://developers.openai.com/codex/windows#windows-sandbox

当你在 Docker 这类 containerized environment（容器化环境）里运行 Linux 时，如果宿主机或容器配置阻止 Codex 所需的 namespace、setuid bwrap 或 seccomp 操作，sandbox 可能无法工作。

这种情况下，请配置 Docker container 来提供你需要的隔离，然后在容器内用 --sandbox danger-full-access 或 --dangerously-bypass-approvals-and-sandbox 运行 codex。

Run Codex in Dev Containers

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

参考实现是 Codex secure devcontainer example：

https://github.com/openai/codex/tree/main/.devcontainer

这个示例会安装 Codex、常见开发工具、bubblewrap，以及基于 firewall 的 outbound controls（出站控制）。

Devcontainers 能提供大量保护，但不能阻止所有攻击。如果你在容器内使用 --sandbox danger-full-access 或 --dangerously-bypass-approvals-and-sandbox，恶意项目仍可能外传 devcontainer 内可访问的任何内容，包括 Codex credentials。只在受信任仓库中使用这个模式，并像监控其他 elevated environment（高权限环境）一样监控 Codex 活动。

参考实现包含：

基于 Ubuntu 24.04 的基础镜像，安装 Codex 和常见开发工具。
基于 allowlist（允许列表）的 outbound firewall profile。
用于在容器中重新打开 workspace 的 VS Code settings 和 extension recommendations。
command history（命令历史）和 Codex configuration 的持久化 mounts。
bubblewrap，这样当容器授予所需 capabilities 时，Codex 仍然可以使用自己的 Linux sandbox。

试用步骤：

安装 Visual Studio Code 和 Dev Containers extension：https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers
把 Codex 示例 .devcontainer 设置复制到你的仓库，或者直接从 Codex 仓库开始。
在 VS Code 中运行 Dev Containers: Open Folder in Container...，选择 .devcontainer/devcontainer.secure.json。
容器启动后，打开终端并运行 codex。

也可以从 CLI 启动容器：

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

示例主要有三部分：

.devcontainer/devcontainer.secure.json 控制 container settings、capabilities、mounts、environment variables 和 VS Code extensions。
.devcontainer/Dockerfile.secure 定义基于 Ubuntu 的镜像和已安装工具。
.devcontainer/init-firewall.sh 应用 outbound network policy。

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

在容器内，选择以下模式之一：

如果 Dev Container profile 授予了 bwrap 创建内层 sandbox 所需的 capabilities，就保留 Codex 的 Linux sandbox。
如果容器就是你的预期安全边界，在容器内使用 --sandbox danger-full-access，让 Codex 不再尝试创建第二层 sandbox。

Version control

Codex 最适合搭配 version control workflow（版本控制工作流）使用：

在 feature branch（功能分支）上工作，并在委托任务前保持 git status 干净。这样更容易隔离和回退 Codex patches。
优先使用 patch-based workflows，例如 git diff / git apply，而不是直接编辑 tracked files。频繁提交，方便小步回滚。
像对待普通 PR 一样对待 Codex 建议：运行聚焦验证、审查 diffs，并在 commit messages 里记录决策，方便审计。

Monitoring and telemetry

Codex 支持 opt-in monitoring（选择性启用监控），通过 OpenTelemetry（OTel）帮助团队审计使用情况、调查问题并满足合规要求，同时不削弱本地安全默认值。

Telemetry 默认关闭。需要时必须在配置中显式启用。

概览

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

Enable OTel（opt-in）

在 Codex 配置中添加 [otel] block，通常是 ~/.codex/config.toml。选择 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，但不向任何地方发送数据。
如果要把 events 发送到你自己的 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 会批量发送 events，并在关闭时 flush（刷新发送）。Codex 只导出由它的 OTel module 产生的 telemetry。

Event categories

代表性 event types 包括：

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：长度；除非显式启用，否则内容会被脱敏。
codex.tool_decision：approved / denied，来源是 configuration 还是 user。
codex.tool_result：duration、success、output snippet。

相关 OTel metrics 包括 codex.api_request、codex.sse_event、codex.websocket.request、codex.websocket.event 和 codex.tool.call。这些指标包含 counter，以及对应的 .duration_ms duration histogram。

完整 event catalog 和配置参考见：

https://github.com/openai/codex/blob/main/docs/config.md#otel

安全和隐私建议

除非策略明确允许存储 prompt 内容，否则保持 log_user_prompt = false。Prompts 可能包含源码和敏感数据。
只把 telemetry 发送到你控制的 collectors。设置与合规要求一致的 retention limits 和 access controls。
把 tool arguments 和 outputs 当作敏感内容处理。尽可能在 collector 或 SIEM 中做 redaction（脱敏）。
如果你不希望 Codex 在 CODEX_HOME 下保存 session transcripts，请检查本地 data retention 设置，例如 history.persistence / history.max_bytes。参考 Advanced Config 和 Configuration Reference：
- https://developers.openai.com/codex/config-advanced#history-persistence
- https://developers.openai.com/codex/config-reference
如果 CLI 运行时网络访问关闭，OTel export 无法访问你的 collector。要导出数据，需要在 workspace-write mode 里允许访问 OTel endpoint，或者从 Codex cloud 导出，并把 collector domain 放入批准列表。
定期检查 events，关注 approval / sandbox changes 和异常 tool executions。

OTel 是可选功能，用来补充而不是替代本篇描述的 sandbox 和 approval 保护。

Managed configuration

Enterprise admins 可以在 Managed configuration 中为 workspace 配置 Codex security settings。设置和策略细节见：

https://developers.openai.com/codex/enterprise/managed-configuration

On this page