Agent 审批与安全

身份 非官方简体中文镜像

翻译状态 AI 翻译 / AI 审校

来源版本 官方未提供

同步日期 2026-07-26

官方原文 learn.chatgpt.com

Codex 有助于保护你的代码和数据，并降低滥用风险。

本页介绍如何安全地运行 Codex，包括沙箱、审批和网络访问。如果你要查找的是 Codex Security（用于扫描已连接的 GitHub 仓库的产品），请参阅 Codex Security。

默认情况下，代理的网络访问处于关闭状态。在本地，Codex 使用由操作系统强制执行的沙箱来限制其可访问的内容（通常仅限当前工作区），并通过审批策略控制何时必须暂停并在执行操作前向你询问。

如需了解 ChatGPT 桌面应用、Codex CLI 和 Codex IDE extension 中沙箱的工作方式，请参阅沙箱。如需更广泛的企业安全概览，请参阅 Codex 安全白皮书。

沙箱与审批

Codex 的安全控制来自两个协同工作的层面：

• 沙箱模式：Codex 执行模型生成的命令时，在技术层面能够执行的操作（例如可以在哪里写入，以及是否能够访问网络）。
• 审批策略：Codex 在执行操作前必须向你询问的时机（例如离开沙箱、使用网络或运行受信任集合之外的命令）。

Codex 会根据运行位置使用不同的沙箱模式：

• Codex cloud：在 OpenAI 管理的隔离容器中运行，防止访问你的主机系统或无关数据。使用两阶段运行时模型：代理阶段开始前先运行 setup，此阶段可以访问网络以安装指定依赖；随后代理阶段默认离线运行，除非你为该环境启用互联网访问。为云环境配置的密钥仅在 setup 期间可用，并会在代理阶段开始前被移除。
• Codex CLI / Codex IDE extension：由操作系统级机制强制执行沙箱策略。默认设置包括不允许网络访问，以及仅向活动工作区授予写入权限。你可以根据风险承受程度配置沙箱、审批策略和网络设置。

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

Codex 会请求批准，以编辑工作区之外的文件或运行需要网络访问的命令。如果你希望只聊天或制定计划而不进行更改，请使用 /permissions 命令切换到 read-only 模式。

即使操作不是 shell 命令或文件更改，Codex 也可以针对声明会产生副作用的应用（连接器）工具调用请求批准。当工具声明了破坏性注解时，破坏性应用/MCP 工具调用始终需要批准，即使它同时声明了其他提示（例如只读提示）。

网络访问 ⚠️ 高风险

对于 Codex cloud，请参阅代理互联网访问，以启用完整的互联网访问或域名允许列表。

对于 ChatGPT 桌面应用、Codex CLI 或 Codex IDE extension，默认的 workspace-write 沙箱模式会保持网络访问关闭，除非你在配置中启用网络访问：

[sandbox_workspace_write]
network_access = true

网络隔离

网络访问通过目标规则进行控制，这些规则适用于由命令启动的脚本、程序和子进程。当命令网络访问已启用时，开启 network_proxy 功能，将流量限制在你配置的网络策略范围内。

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

对于一次性 CLI 会话，如果只需要切换开关，请使用布尔值简写；如果还要设置策略选项，请使用表格形式：

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'

该功能会改变已启用网络访问的强制方式；它本身不会授予网络访问权限。使用 workspace-write 配置中的 sandbox_workspace_write.network_access，决定命令是否具有网络访问权限：

• 网络关闭 + network_proxy 开启：网络仍然关闭，该功能不执行任何操作。
• 网络开启 + network_proxy 关闭：网络仍然开启，并具有不受限制的直接出站访问权限。
• 网络开启 + network_proxy 开启：网络仍然开启，出站流量会受到已配置网络策略的限制。

管理员管理的 experimental_network 要求独立于用户功能开关。管理员可以在不使用 features.network_proxy 的情况下配置并启动沙箱网络，但如果活动沙箱保持网络关闭状态，这些要求不会开启网络访问。有关管理员端 requirements.toml 的结构，请参阅托管配置。

网络策略

域名规则以允许列表优先：

• 精确主机名只匹配自身。
• *.example.com 匹配 api.example.com 等子域名，但不匹配 example.com。
• **.example.com 同时匹配顶级域名和子域名。
• 全局 * 允许规则匹配所有未被拒绝的公共主机。应将 * 视为广泛的网络访问，并尽可能优先使用范围明确的规则。
• deny 始终优先于 allow，全局 * 仅对允许规则有效。

本地和私有目标

默认情况下，allow_local_binding = false 会阻止回环、链路本地和私有目标：

• 特定例外：当命令需要一个本地目标时，添加精确的本地 IP 字面量或 localhost 允许规则。
• 更广泛的访问：只有在确实需要更广泛的本地/私有访问时，才将 allow_local_binding = true。
• 通配符：通配符规则不算作显式本地例外。
• 解析后的地址：即使主机名匹配允许列表，只要其解析为本地/私有 IP，仍会被阻止。

DNS 重绑定保护

在允许某个主机名之前，Codex 会尽力执行 DNS 和 IP 分类检查：

• 失败或超时的查询会被阻止。
• 解析为非公共地址的主机名会被阻止。
• 该检查可以降低 DNS 重绑定风险，但无法消除风险。要完全防止重绑定，需要通过传输层固定解析后的 IP。

如果恶意 DNS 属于威胁范围，还应在更低层级强制执行出站控制。

危险设置

以下两个设置会有意扩大信任边界：

• dangerously_allow_non_loopback_proxy = true 可能会使代理监听器暴露到回环地址之外。
• dangerously_allow_all_unix_sockets = true 会绕过 Unix socket 允许列表。

仅在严格受控的环境中使用这些设置。启用 Unix socket 代理时，即使请求了非回环绑定，监听器仍会保持仅限回环访问，因此沙箱网络不会变成通往本地守护进程的远程桥梁。

默认情况下，network_proxy 处于关闭状态。启用后：

设置	默认值	行为
enabled	false	仅当命令网络访问已开启时，才启动沙箱网络。
domains	未设置	使用允许列表行为，因此在添加 allow 规则前，不允许任何外部目标。支持精确主机名、范围明确的通配符和全局 * 允许规则；deny 始终优先。
unix_sockets	未设置	在添加显式 allow 规则前，不允许任何 Unix socket 目标。
allow_local_binding	false	阻止本地和私有网络目标，除非添加精确的本地 IP 字面量或 localhost 允许规则，或明确选择更广泛的本地/私有访问。
enable_socks5	true	在策略允许时提供 SOCKS5 支持。
enable_socks5_udp	true	SOCKS5 可用时允许通过 SOCKS5 使用 UDP。
allow_upstream_proxy	true	允许沙箱网络使用环境中的上游代理。
dangerously_allow_non_loopback_proxy	false	使监听端点保持在回环地址，除非你有意将其暴露到 localhost 之外。
dangerously_allow_all_unix_sockets	false	使 Unix socket 访问基于允许列表，除非你有意绕过该保护。

你还可以控制网页搜索工具，而无需授予已启动命令完整的网络访问权限。Codex 默认使用网页搜索缓存来访问结果。该缓存是 OpenAI 维护的网页结果索引，因此缓存模式会返回预先建立索引的结果，而不是获取实时页面。这可以减少任意实时内容带来的提示注入风险，但你仍应将网页搜索结果视为不受信任的内容。如果你使用 --yolo 或其他完整访问沙箱设置，网页搜索默认使用实时结果。使用 --search 或将 web_search = "live" 设置为允许实时浏览，或将其设置为 "disabled" 以关闭该工具：

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

当外部网页访问应由搜索索引控制时，设置 web_search = "indexed"。在 Codex 中启用网络访问或网页搜索时请谨慎。提示注入可能导致代理获取并遵循不受信任的指令。

默认设置与建议

• 启动时，Codex 会检测文件夹是否受版本控制，并给出建议：
  • 受版本控制的文件夹：Auto（工作区写入 + 按请求审批）
  • 不受版本控制的文件夹：read-only
• 根据你的设置，Codex 也可能先以 read-only 模式启动，直到你明确信任工作目录（例如通过引导提示或 /permissions）。
• 工作区包括当前目录和 /tmp 等临时目录。使用 /status 命令查看哪些目录位于工作区中。
• 要接受默认设置，请运行 codex。
• 你可以显式设置：
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

可写根目录中的受保护路径

在默认的 workspace-write 沙箱策略下，可写根目录仍包含受保护路径：

• <writable_root>/.git 无论显示为目录还是文件，均受保护，只读。
• 如果 <writable_root>/.git 是指针文件（gitdir: ...），解析出的 Git 目录路径也受保护，只读。
• 如果 <writable_root>/.agents 作为目录存在，则受保护，只读。
• 如果 <writable_root>/.codex 作为目录存在，则受保护，只读。
• 保护是递归的，因此这些路径下的所有内容均为只读。

在不显示审批提示的情况下运行

你可以使用 --ask-for-approval never 或简写形式 -a never 禁用审批提示。

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

如果你需要 Codex 在不显示审批提示的情况下读取文件、进行编辑并使用网络访问运行命令，请使用 --sandbox danger-full-access（或 --dangerously-bypass-approvals-and-sandbox 标志）。使用前请谨慎评估。

作为折中方案，approval_policy = { granular = { ... } } 允许你保留特定审批提示类别的交互式确认，同时自动拒绝其他类别。细粒度策略涵盖沙箱审批、execpolicy-rule 提示、MCP 提示、request_permissions 提示和技能脚本审批。

自动审批审查

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

approvals_reviewer = "user"

自动审批审查适用于交互式审批，例如 approval_policy = "on-request" 或细粒度审批策略。设置 approvals_reviewer = "auto_review"，即可在 Codex 运行请求前，将符合条件的审批请求转交给审查代理：

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

有关完整的审查流程、触发条件、配置优先级和失败行为，请参阅自动审查。

审查代理仅评估本来就需要审批的操作，例如沙箱权限提升、被阻止的网络请求、request_permissions 提示，或会产生副作用的应用和 MCP 工具调用。在沙箱内执行的操作会继续运行，无需额外的审查步骤。

审查策略会检查数据外泄、凭据探测、持续削弱安全性以及破坏性操作。策略允许时，低风险和中风险操作可以继续执行。策略会拒绝严重风险操作。高风险操作需要足够的用户授权，且不能匹配任何拒绝规则。提示构建、审查会话和解析失败时会默认拒绝。超时会单独显示，但操作仍不会运行。

默认审查策略位于开源 Codex 仓库中。企业可以在托管要求中使用 guardian_policy_config 替换其中面向租户的部分。也支持本地 [auto_review].policy 文本，但托管要求具有更高优先级。有关设置详情，请参阅托管配置。

在 ChatGPT 桌面应用中，这些审查会显示为自动审查项目，并带有 Reviewing、Approved、Denied、Aborted 或 Timed out 等状态。它们还可能包含所审查请求的风险级别和用户授权评估。

自动审查会使用额外的模型调用，因此可能增加 Codex 用量。管理员可以使用 allowed_approvals_reviewers 对其进行限制。

常见沙箱与审批组合

意图	标志 / 配置	效果
Auto（预设）	无需标志 或 --sandbox workspace-write --ask-for-approval on-request	Codex 可以读取工作区中的文件、进行编辑并运行命令。编辑工作区之外的文件或访问网络时，Codex 需要获得批准。
安全的只读浏览	--sandbox read-only --ask-for-approval on-request	Codex 可以读取文件并回答问题。进行编辑、运行命令或访问网络时，Codex 需要获得批准。
非交互式只读（CI）	--sandbox read-only --ask-for-approval never	Codex 只能读取文件，且不会请求批准。
自动编辑，但运行不受信任的命令前请求批准	--sandbox workspace-write --ask-for-approval untrusted	Codex 可以读取和编辑文件，但运行不受信任的命令前会请求批准。
自动审查模式	--sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review 或 approvals_reviewer = "auto_review"	与标准的按请求审批模式具有相同的沙箱边界，但符合条件的审批请求会由自动审查处理，而不是显示给用户。
危险的完整访问权限	--dangerously-bypass-approvals-and-sandbox（别名：--yolo）	⚠️ 高风险：无沙箱；无审批（不建议）

对于非交互式运行，请使用 codex exec --sandbox workspace-write；Codex 会将旧版 codex exec --full-auto 调用保留为已弃用的兼容路径，并显示警告。

使用 --ask-for-approval untrusted 时，Codex 只会自动运行已知安全的读取操作。可能改变状态或触发外部执行路径的命令（例如具有破坏性的 Git 操作，或 Git 输出/配置覆盖标志）需要获得批准。

config.toml 中的配置

有关更广泛的配置流程，请参阅配置基础、高级配置和配置参考。

# 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
# } }

你还可以将预设保存为配置文件，然后使用 codex --profile profile-name 选择它们：

~/.codex/full_auto.config.toml

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

~/.codex/readonly_quiet.config.toml

approval_policy = "never"
sandbox_mode    = "read-only"

在本地测试沙箱

要了解命令在 Codex 沙箱中运行时的情况，请使用以下 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 使用，并且平台辅助工具提供了别名（例如 codex sandbox seatbelt 和 codex sandbox landlock）。

操作系统级沙箱

Codex 会根据你的操作系统采用不同的沙箱实现：

• macOS 使用 Seatbelt 策略，并通过带有配置文件（-p）的 sandbox-exec 运行命令；该配置文件对应你选择的 --sandbox 模式。当受限读取权限启用平台默认设置时，Codex 会附加经过筛选的 macOS 平台策略（而不是广泛允许访问 /System），以保持常用工具的兼容性。
• Linux 默认使用 bwrap 和 seccomp。
• Windows 在 Windows Subsystem for Linux 2 (WSL2) 中运行时使用 Linux 沙箱实现。WSL1 通过 Codex 0.114 受到支持；从 0.115 开始，Linux 沙箱改用 bwrap，因此不再支持 WSL1。在 Windows 原生运行时，Codex 使用 Windows 沙箱实现。

如果你在 Windows 上使用 Codex IDE extension，它可以直接支持 WSL2。请在 VS Code 设置中添加以下配置，以便在 WSL2 可用时始终让代理在其中运行：

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

这样可以确保即使主机操作系统是 Windows，Codex IDE extension 在命令、审批和文件系统访问方面仍继承 Linux 沙箱语义。详情请参阅 WSL 指南。

在 Windows 原生运行时，请在 config.toml 中配置原生沙箱模式：

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

详情请参阅 Windows 设置指南。

当你在 Docker 等容器化环境中运行 Linux 时，如果主机或容器配置阻止了 Codex 所需的命名空间、setuid bwrap 或 seccomp 操作，沙箱可能无法正常工作。

此时，请配置 Docker 容器以提供所需的隔离，然后在容器内使用 --sandbox danger-full-access（或 --dangerously-bypass-approvals-and-sandbox 标志）运行 codex。

在 Dev Containers 中运行 Codex

如果你的主机无法直接运行 Linux 沙箱，或者你的组织已经统一采用容器化开发，请使用 Dev Containers 运行 Codex，并让 Docker 提供外层隔离边界。此方式适用于 Visual Studio Code Dev Containers 和兼容工具。

请将 Codex 安全 devcontainer 示例作为参考实现。该示例会安装 Codex、常用开发工具、bubblewrap 以及基于防火墙的出站控制。

Dev Containers 可以提供较强的保护，但无法阻止每一种攻击。如果你在容器内使用 --sandbox danger-full-access 或 --dangerously-bypass-approvals-and-sandbox 运行 Codex，恶意项目可以窃取 Dev Container 内可访问的任何内容，包括 Codex 凭据。仅在受信任的代码仓库中使用此模式，并像对待任何其他高权限环境一样监控 Codex 活动。

参考实现包含：

• 基于 Ubuntu 24.04 的基础镜像，其中已安装 Codex 和常用开发工具；
• 由允许列表驱动的出站访问防火墙配置；
• 用于在容器中重新打开工作区的 VS Code 设置和扩展推荐；
• 用于持久化命令历史记录和 Codex 配置的挂载；
• bubblewrap，使 Codex 在容器授予所需能力时仍可使用其 Linux 沙箱。

尝试使用：

1. 安装 Visual Studio Code 和 Dev Containers 扩展。
2. 将 Codex 示例中的 .devcontainer 设置复制到你的代码仓库，或直接从 Codex 代码仓库开始。
3. 在 VS Code 中运行 Dev Containers: Open Folder in Container…，然后选择 .devcontainer/devcontainer.secure.json。
4. 容器启动后，打开终端并运行 codex。

你还可以通过 CLI 启动容器：

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

该示例包含三个主要部分：

• .devcontainer/devcontainer.secure.json 控制容器设置、能力、挂载、环境变量和 VS Code 扩展。
• .devcontainer/Dockerfile.secure 定义基于 Ubuntu 的镜像和已安装的工具。
• .devcontainer/init-firewall.sh 应用出站网络策略。

参考防火墙有意设计为起点。如果你依赖域名允许列表来实现隔离，请根据你的环境实施 DNS 重绑定和 DNS 刷新保护，例如支持 TTL 的刷新机制或 DNS 感知型防火墙。

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

• 如果 Dev Container 配置文件授予 bwrap 创建内部沙箱所需的能力，请保持 Codex 的 Linux 沙箱启用。
• 如果容器就是你计划使用的安全边界，请在容器内使用 --sandbox danger-full-access 运行 Codex，以便 Codex 不再尝试创建第二层沙箱。

版本控制

Codex 最适合配合版本控制工作流使用：

• 在功能分支上工作，并在委托任务前保持 git status 干净。这样可以更容易地隔离和还原 Codex 补丁。
• 优先使用基于补丁的工作流（例如 git diff/git apply），而不是直接编辑已跟踪文件。频繁提交，以便按小步回滚。
• 像对待其他 PR 一样对待 Codex 的建议：执行有针对性的验证、检查差异，并在提交消息中记录决策以便审计。

监控与遥测

Codex 支持通过 OpenTelemetry (OTel) 选择性启用监控，帮助团队审计使用情况、调查问题并满足合规要求，同时不削弱本地安全默认设置。遥测默认关闭；请在配置中明确启用。

概览

• Codex 默认关闭 OTel 导出，以保持本地运行自包含。
• 启用后，Codex 会发出结构化日志事件，涵盖聊天、API 请求、SSE/WebSocket 流活动、用户提示词（默认已编辑）、工具审批决策和工具结果。
• Codex 会使用 service.name（发起方）、CLI 版本和环境标签标记导出的事件，以区分开发、预发布和生产流量。

启用 OTel（选择性启用）

在 Codex 配置中添加一个 [otel] 区块（通常位于 ~/.codex/config.toml），选择导出器以及是否记录提示词文本。

[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" 会使检测保持启用，但不会将数据发送到任何位置。
• 要将事件发送到你自己的收集器，请选择以下选项之一：

[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 会批量处理事件，并在关闭时刷新。Codex 仅导出其 OTel 模块生成的遥测数据。

事件类别

代表性事件类型包括：

• codex.conversation_starts（模型、推理设置、沙箱/审批策略）
• codex.api_request（尝试次数、状态/成功情况、持续时间和错误详情）
• codex.sse_event（流事件类型、成功/失败情况、持续时间，以及 response.completed 中的令牌数量）
• codex.websocket_request 和 codex.websocket_event（请求持续时间，以及每条消息的类型/成功情况/错误）
• codex.user_prompt（长度；除非明确启用，否则内容会被编辑）
• codex.tool_decision（已批准/已拒绝，来源：配置或用户）
• codex.tool_result（持续时间、成功情况、输出片段）

关联的 OTel 指标（计数器与持续时间直方图成对出现）包括 codex.api_request、codex.sse_event、codex.websocket.request、codex.websocket.event 和 codex.tool.call（以及对应的 .duration_ms 指标）。

完整的事件目录和配置参考请参阅 GitHub 上的 Codex 配置文档。

安全与隐私指南

• 除非相关政策明确允许存储提示词内容，否则请保持 log_user_prompt = false。提示词可能包含源代码和敏感数据。
• 仅将遥测数据发送到你控制的收集器；根据合规要求应用保留期限和访问控制。
• 将工具参数和输出视为敏感信息。可能时，优先在收集器或 SIEM 中进行编辑。
• 如果不希望 Codex 将会话记录保存到 CODEX_HOME 下，请检查本地数据保留设置（例如 history.persistence / history.max_bytes）。请参阅高级配置和配置参考。
• 如果运行 CLI 时关闭了网络访问，OTel 导出将无法连接到你的收集器。要导出数据，请在 workspace-write 模式下允许访问 OTel 端点的网络，或从 Codex cloud 导出，并将收集器域名加入批准列表。
• 定期检查事件，以发现审批/沙箱变更和意外的工具执行。

OTel 是可选功能，旨在补充而非替代上述沙箱和审批保护措施。

托管配置

企业管理员可以在托管配置中为其工作区配置 Codex 安全设置。有关设置和策略详情，请参阅该页面。