智能体审批与安全

Codex 可帮助保护您的代码和数据，并降低滥用风险。

默认情况下，智能体在关闭网络访问的状态下运行。在本地，Codex 使用由操作系统强制执行的沙盒来限制可访问的范围（通常仅限当前工作空间），并通过审批策略决定何时必须在操作前暂停并向您请求审批。

如需了解沙盒在 ChatGPT 桌面应用、 Codex CLI 和 IDE 扩展中的基本工作原理，请参阅沙盒。 如需更全面地了解企业安全，请参阅 Codex 安全白皮书。

从已停用的 untrusted 审批策略迁移

Codex 和 ChatGPT Work 不再支持 approval_policy = "untrusted"。 这项已停用的设置可能导致这两个客户端无法启动。请从 用户或项目配置、配置方案文件、启动脚本和托管默认设置中 移除它。如需以交互式只读方式使用，请采用以下配置：

sandbox_mode = "read-only"
approval_policy = "on-request"

或者运行 codex --sandbox read-only --ask-for-approval on-request。

使用 on-request 时，沙盒允许的命令无需审批即可运行， 可读取有权访问的文件，并在网络访问已启用时使用网络。

如需保留更严格的命令审批规则，请勿显式设置 approval_policy，并在用户级配置文件 ~/.codex/config.toml 中添加项目条目：

[projects."/path/to/project"]
trust_level = "untrusted"

这样一来，命令都需要审批，除非执行策略规则允许其运行。 这也会禁用项目本地配置。显式设置 on-request 会覆盖根据项目确定的策略；托管的 allowed_approval_policies 必须 包含 untrusted 才能允许使用该项目策略。

沙盒与审批

Codex 的安全控制由相互配合的两个层面构成：

• 沙盒模式：Codex 执行模型生成的命令时，在技术上能够执行哪些操作，例如可以写入哪些位置，以及能否访问网络。
• 审批策略：Codex 在什么情况下必须先征求您的同意才能执行操作，例如在沙盒外执行操作、使用网络或运行不在受信任集合中的命令。

Codex 会根据运行环境采用不同的沙盒模式：

• Codex 云端：在由 OpenAI 管理的隔离容器中运行，无法访问您的主机系统或无关数据。运行过程分为两个阶段：设置阶段先于智能体阶段运行，可以访问网络以安装指定的依赖项；随后进入智能体阶段，默认离线运行，除非您为该环境启用了互联网访问。为云端环境配置的密钥仅在设置阶段可用，并在智能体阶段开始前移除。
• Codex CLI / IDE 扩展：通过操作系统级机制强制执行沙盒策略。默认不允许网络访问，写入权限仅限当前工作空间。您可以根据自己的风险承受能力配置沙盒、审批策略和网络设置。

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

Codex 在编辑工作空间以外的文件或运行需要网络访问的命令时，会请求审批。如果您只想聊天或制订计划而不做更改，请使用 /permissions 命令切换到 read-only 模式。

对于声明会产生副作用的应用（连接器）工具调用，Codex 也可以请求审批，即使这些操作并非 shell 命令或文件更改。当工具声明了破坏性注解时，具有破坏性的应用/MCP 工具调用始终需要审批，除非该工具还声明了读取注解，此时读取注解优先。

安全监控与任务暂停

GPT-6 Astra 在 Codex 和 ChatGPT Work 中提供安全监控。监控以异步方式运行，如果检测到可能不安全的模型行为，可以暂停任务。任务暂停可能发生在触发暂停的活动之后；监控不能替代沙盒、权限控制或对结果的审查。

如果任务暂停，请阅读通知，并在有检测结果时进行审查。只有确认任务可以安全继续后，才能恢复。如果通知说明任务已结束，或未提供恢复选项，您就无法从该界面恢复任务。

安全监控会评估任务执行过程中的模型行为。 自动审批审查则针对本就需要审批的单个操作， 在操作执行前进行评估。即使某项操作已通过自动审批审查， 其所属任务仍可能随后被安全监控暂停。

网络访问 Elevated Risk

对于 Codex 云端，请参阅智能体互联网访问，了解如何启用完整互联网访问或域名允许列表。

对于 ChatGPT 桌面应用、Codex CLI 或 IDE 扩展，默认的 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'

此功能改变的是已启用的网络访问所受的约束方式； 它本身不会授予网络访问权限。请结合 sandbox_workspace_write.network_access 与 workspace-write 配置，决定是否允许命令访问网络：

• 网络关闭 + network_proxy 开启：网络保持关闭，此功能不起作用。
• 网络开启 + network_proxy 关闭：网络保持开启，可不受限制地 直接向外访问。
• 网络开启 + network_proxy 开启：网络保持开启，出站流量 受已配置的网络策略约束。

代理功能也适用于权限配置方案。 配置方案中的 network.enabled = true 授予命令网络访问权限， 而 features.network_proxy = true 则启用该配置方案中 域名规则的强制执行：

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

如果您在此示例中省略代理功能，命令将可以直接访问网络， 且 api.openai.com 允许规则不会限制其目标地址。

管理员托管的 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 套接字允许列表。

请仅在严格受控的环境中使用这些设置。启用 Unix 套接字代理后，即使请求绑定非回环地址，监听器也仍仅绑定回环地址，以免沙盒网络成为远程访问本地守护进程的桥梁。

network_proxy 默认关闭。启用后的行为如下：

命令网络代理之外的流量

网络代理会过滤在本地命令沙盒中运行的脚本、程序和子进程的流量。它不会过滤网页搜索、应用或连接器工具调用、MCP 服务器连接、浏览器或计算机使用活动、Codex 云端任务，也不会过滤客户端的模型请求和身份验证请求。这些功能使用独立的服务连接、功能设置、工作空间策略或环境控制。

浏览器工具在访问某个源之前，会单独检查托管的网络拒绝规则和排他性允许列表。 浏览器源策略可以进一步限制站点访问、 上传、下载和开发者工具。请参阅 托管浏览器控制。

对于受管理的用户，请将命令网络策略与其他控制措施结合使用，例如 allowed_web_search_modes、经批准的 mcp_servers，以及 针对应用、插件、浏览器或计算机使用的功能要求。请参阅 托管配置。

您也可以控制网页搜索工具，而不向启动的命令授予完整的网络访问权限。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 规则提示、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 桌面应用中，这些审查会显示为自动审查条目，并带有“审查中”“已批准”“已拒绝”“已中止”或“已超时”等状态。条目还可以包含所审查请求的风险级别和用户授权评估。

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

常见沙盒与审批组合

对于非交互式运行，请使用 codex exec --sandbox workspace-write；Codex 仍兼容旧的 codex exec --full-auto 调用方式，但已弃用此方式，并会输出警告。

config.toml 中的配置

有关更完整的配置工作流程，请参阅基础配置、高级配置和配置参考资料。

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
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 策略，并通过 sandbox-exec 运行命令，所用配置方案（-p）与您选择的 --sandbox 模式对应。当受限读取访问启用平台默认设置时，Codex 会追加一套经过精心选择的 macOS 平台策略（而非全面放行 /System），以保持与常用工具的兼容性。
• Linux 默认结合使用 bwrap 和 seccomp。
• Windows ：在 Windows Subsystem for Linux 2（WSL2） 中运行时，使用 Linux 沙盒实现。Codex 对 WSL1 的支持截至 0.114 版本；从 0.115 开始，Linux 沙盒改用 bwrap，因此不再支持 WSL1。在 Windows 上原生运行时，Codex 使用 Windows 沙盒实现。

如果您在 Windows 上使用 Codex IDE 扩展，该扩展直接支持 WSL2。在 VS Code 设置中添加以下配置，即可在 WSL2 可用时始终让智能体在其中运行：

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

这能确保即使主机操作系统是 Windows，IDE 扩展在命令、审批和文件系统访问方面也遵循 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 安全开发容器示例作为参考实现。该示例会安装 Codex、常用开发工具、bubblewrap 以及基于防火墙的出站访问控制。

参考实现包含：

• 已安装 Codex 和常用开发工具的 Ubuntu 24.04 基础镜像；
• 基于允许列表控制出站访问的防火墙配置方案；
• 用于在容器中重新打开工作空间的 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 配置（通常为 ~/.codex/config.toml）中添加一个 [otel] 配置块，选择导出器，并指定是否记录提示文本。

[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 中的 Token 数量）
• 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 云端导出。
• 定期审查事件，检查审批或沙盒变更，以及意料之外的工具执行。

OTel 是可选功能，旨在补充而非取代上述沙盒和审批保护机制。

托管配置

企业管理员可以通过托管配置为其工作空间配置 Codex 安全设置。有关设置和策略的详细信息，请参阅该页面。