Codex 安全配置指南

如果员工应通过公司的 ChatGPT 工作区登录 Codex，并且受管理终端上禁止使用个人 ChatGPT 账户和 API key 身份验证，请使用此方案。

预期结果

在公司管理的设备上，Codex 仅接受通过 ChatGPT 登录公司的 ChatGPT 工作区。

前提条件

• 已批准的 ChatGPT Enterprise 工作区的 UUID。

• 向终端分发 Codex 托管配置的方式。

• 已决定在受管理终端上禁止 API key 身份验证。

配置

1. 在内部配置仓库中记录已批准的工作区 UUID。

2. 在本地 requirements.toml 中添加强制身份验证要求：

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

第一个键仅允许 ChatGPT 身份验证；第二个键将登录限制在已批准的工作区。请将示例 UUID 替换为你的工作区 UUID。参阅要求参考。

3. 按照配置应放在哪里中的路径，通过本地 requirements.toml 或 macOS MDM 要求部署。这些身份验证要求在凭据加载和云端策略获取之前生效；Codex 会忽略云端托管要求中的这些设置。请保护文件及其父目录，防止用户修改。旧版 managed_config.toml 默认值不会强制执行此限制。

4. 试点期间，让用户退出登录，或移除此前保存的个人 Codex 会话。不要假定新策略会追溯性地使现有会话失效。

5. 将登录限制与工作区角色和群组访问权限结合使用。身份验证控制以哪个身份登录；RBAC 控制该身份可以使用哪些 Codex 功能。参阅身份验证。

验证

• 退出 Codex 登录。

• 尝试使用个人 ChatGPT 账户登录。预期：登录个人工作区被拒绝。

• 尝试使用 Codex API key 登录。预期：API key 登录被拒绝。

• 使用公司账户登录已批准的工作区。预期：登录成功。

• 重启桌面应用、CLI 和 IDE 扩展，然后重复上述检查。

回滚

恢复此前的本地身份验证要求，并重新部署已审核的配置包。

适用边界

此配置控制受管理终端上的受管理 Codex 客户端。如果要求是“禁止通过公司资产将 Codex 用于个人用途”，请结合终端应用控制和网络策略。

如果开发者需要只读访问或限定在工作区内的访问，而你希望防止他们选择完全访问权限，或使用 --yolo 绕过审批和沙箱，请使用此方案。

预期结果

用户只能选择已批准的只读或工作区范围配置档案，无法选择 danger-full-access、approval_policy = "never" 或 --yolo。

配置

1. 定义已批准的工作区配置档案：

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. 强制执行允许的配置档案和审批策略：

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

允许列表具有排他性：未列入允许列表或设为 false 的配置档案均被拒绝，包括未来版本中新增的配置档案。参阅配置参考。

3. 对于仍使用 sandbox_mode 的旧版客户端，请使用：

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. 将此配置作为管理员强制执行的要求下发，而不是作为用户可编辑的配置文件。

5. 如果之后允许自动审核，请在测试后有意识地添加。自动审核改变的是由谁审核跨越边界的操作；它不会恢复已移除的边界。参阅自动审核。

验证

• 打开权限选择器。预期：完全访问权限不可用或被拒绝。

• 使用 --dangerously-bypass-approvals-and-sandbox 启动。预期：Codex 拒绝启动，或强制使用兼容的配置档案。

• 使用 --sandbox danger-full-access --ask-for-approval never 启动。预期：启动被拒绝。

• 执行常规工作区任务。预期：任务成功；跨越边界仍需审批。

回滚

恢复此前的要求配置包。除非存在单独批准的例外，否则继续阻止不受限制的访问。

适用边界

此配置控制 Codex 运行时权限。它不会将拥有特权的操作系统账户变为非特权账户。

如果组织需要决定 Codex 可以使用哪些 MCP server，并强制执行批准列表，请使用此方案。

允许某台服务器与配置该服务器是两个独立步骤。允许列表条目允许使用匹配的服务器，但不会创建服务器配置。请另行配置服务器，使用匹配的名称和身份信息，并配置所需的身份验证。

预期结果

Codex 仅启用配置的名称和身份信息与企业批准列表匹配的 MCP server。

配置

1. 盘点每台已批准服务器的信息：负责人、用途、传输方式、确切的可执行文件或 URL、身份验证、数据分类，以及具备写入能力的工具。

2. 从全部拒绝开始。空的托管表会禁用所有 MCP server：

   [mcp_servers]

3. 按确切 URL 添加已批准的 HTTP 服务器：

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. 按可执行文件和位置参数添加已批准的 stdio 服务器：

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

结构化匹配器会检查可执行文件、参数数量和参数顺序。它不会约束 cwd、env 或 env_vars。应将控制完整启动上下文视为批准 stdio 服务器的前提：保护其可执行文件和依赖项，并防止不受信任的用户或项目配置提供可能改变其行为的工作目录或环境。如果无法独立强制执行该边界，请勿批准该 stdio 服务器，改用经过审核的 HTTP 服务器。

5. 在 plugins.<plugin>.mcp_servers.<server> 下单独添加插件捆绑的 MCP 身份信息。

6. 将批准列表存储在经过审核的配置仓库中，并通过管理员强制执行的要求部署。

客户端仅在服务器的名称和身份信息均与已批准条目匹配时才会启用该服务器。参阅托管配置。

验证

• 严格按要求配置已批准的服务器。预期：服务器启动。

• 更改 URL 中的一个字符。预期：服务器被禁用。

• 更改 stdio 参数数量或顺序，或提供不符合已配置参数规则的参数。预期：服务器被禁用。仍满足允许前缀的值依然被允许。

• 在可随时丢弃的可信项目中，保持可执行文件和参数匹配，同时尝试无害的 cwd、env 和 env_vars 覆盖设置。仅靠身份匹配不会拒绝这些覆盖设置。请验证独立的启动上下文控制措施会拒绝不安全的覆盖设置，或确保该 stdio 服务器仍未获批准；不要使用真实的注入载荷。

• 添加未经批准的名称。预期：服务器被禁用。

• 测试插件捆绑的服务器。预期：服务器仅在身份信息获批准时才能工作。

回滚

移除新增条目。若要立即停止所有 MCP 使用，请部署空的 mcp_servers 表。

适用边界

身份允许列表并不能证明服务器的工具、上游数据、凭据或启动环境是安全的。本地 stdio MCP 进程在本地命令沙箱之外运行；可执行文件和参数匹配并不会限制服务器的访问权限，也不会阻止通过环境加载代码。请独立审核完整启动上下文和服务器权限。参阅 MCP 身份要求。

如果安全团队需要了解 Codex 在终端和网络中执行的操作，请使用此方案。它汇集运行和工具事件、审批决策、工作区审计记录以及网络日志，以供调查。

预期结果

安全团队可以关联 Codex 运行、工具决策、审批、工作区审计记录和实际网络出站流量，而无需依赖模型自身的描述。

使用四类证据来源

1. Codex OpenTelemetry：运行、API、模型、沙箱、审批和工具事件。

2. 托管生命周期钩子：终端侧有关工具使用和权限请求的记录。

3. 网络代理或网关日志：实际 DNS/HTTP 目标和连接结果。

4. Compliance API：工作区级别的审计和调查记录。

任何单一来源都无法提供完整的网络监控。

配置

1. 将 Codex OpenTelemetry 日志发送到收集器，并隐去原始提示词：

   [otel]
   environment = "enterprise"
   log_user_prompt = false

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

在启动客户端前，通过已批准的机密管理器或进程环境向 Codex 进程提供 OTLP_TOKEN。不要将令牌放入已部署的 TOML 文件或源代码管理系统。

Codex 可以生成对话开始、API 请求、流式事件、提示词元数据、工具决策和工具结果等事件。参阅高级配置。

2. 在项目本地配置之外部署 OTel。项目中的 .codex/config.toml 文件无法覆盖遥测路由。

3. 为 SessionStart、PreToolUse、PermissionRequest、PostToolUse、Stop 和 SessionEnd 添加托管生命周期钩子。

4. 将钩子脚本安装在管理员管理的目录中；如果应忽略用户、项目和插件钩子，请设置 allow_managed_hooks_only = true。

5. 将沙箱命令流量路由至独立记录日志的代理。OTel 记录工具已运行；代理记录子进程尝试连接的位置。

6. 为网页搜索、应用、连接器、MCP server、浏览器活动和 Codex Cloud 单独配置遥测。本地命令代理规则不会自动覆盖这些活动。

7. 将受支持的 Compliance API 记录流式传输至 SIEM，并应用你自己的保留和法律保全控制措施。参阅 Compliance API 和审计事件。

8. 关联用户或服务账户、主机或运行器、对话 ID、模型、客户端版本、权限配置档案、审批决策、目标和工具名称。

验证

运行一个受控会话，执行以下操作：

• 读取一个允许的文件。

• 尝试读取一个被阻止的文件。

• 运行一条允许的命令。

• 尝试发起一个被阻止的出站请求。

• 请求审批并收到拒绝。

• 结束会话。

各证据来源的预期结果：

• OTel 显示运行和工具事件。

• 钩子显示会话生命周期。

• 代理日志显示允许和阻止的目标。

• Compliance 数据接入流程收到受支持的记录。

• SIEM 将这些记录与用户或工作负载关联。

回滚

恢复此前的配置，以禁用导出器和钩子。遥测回滚时，不要移除独立的代理日志记录。

适用边界

不要承诺 Codex 遥测会捕获每个命令参数、每个输出字节或每个网络数据包。请记录各层的覆盖范围。

如果 Codex 应无法访问互联网，或只能访问已批准的目标，请使用此方案。根据要配置的环境，选择本地或云端操作流程，并注意各自独立的策略范围。

预期结果

根据所选配置，Codex 无法访问互联网，或只能访问已批准的域名。Codex Cloud (Legacy) 环境还可以限制 HTTP 方法。

配置当前 Codex Cloud

1. 为不同信任级别创建独立环境，例如 no-internet-review、approved-dependencies-build 和 cyber-lab。

2. 在环境配置中，除非工作流需要互联网访问，否则保持 Allow Codex to access internet 关闭。

3. 需要访问时，开启 Allow Codex to access internet。在 Allow domains 下选择 Custom domains only，然后在 Additional allowed domains 下添加所需的确切主机名。

4. 在设置期间保存并测试服务。发布或重新发布环境，然后在新任务中测试对已批准和未批准目标的访问。单独审核设置脚本：固定依赖项版本，优先使用已批准的镜像，避免下载未经审核的可执行文件。

参阅连接服务。当前 Codex Cloud 设置不提供 Legacy 版本中的 HTTP 方法选择器。

配置 Codex Cloud (Legacy)

1. 无需访问时，将智能体互联网访问保持为 Off。Legacy Cloud 默认在智能体阶段阻止互联网访问；设置脚本仍可访问互联网，以安装依赖项。

2. 智能体需要访问时，将其设为 On，并使用严格的允许列表。从 None 开始，添加确切域名。

3. 对于仅下载的工作流，只允许 GET、HEAD 和 OPTIONS。这会阻止 POST、PUT、PATCH、DELETE 及其他方法。请单独审核设置脚本，因为智能体阶段的限制不约束这些脚本的互联网访问。

参阅 Legacy 智能体互联网访问。这些预设和 HTTP 方法控制仅适用于 Legacy Cloud。

配置本地 Codex

1. 在管理员管理的 requirements.toml 中，定义并选择已批准的网络配置档案，并将用户限制为只能使用该配置档案：

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. 按照托管配置部署经过审核的要求配置包。仅定义命名配置档案并不会使其生效；default_permissions 用于选择它，允许列表则防止选择其他配置档案。

3. 在同一要求配置包中启用管理员管理的代理，以强制执行域名限制，并防止用户扩大范围。请将代理与启用网络的配置档案一同部署；如果没有启用代理，启用网络的配置档案会授予直接网络访问权限，而不会强制执行其中的域名规则：

   注意：[experimental_network] 为实验性功能，可能会发生变化。在扩大部署前，请在每个受支持的本地客户端版本和操作系统上进行验证。Windows 支持有限；在你的环境中测试并确认限制得到强制执行前，不要将此策略应用于 Windows 用户。

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. 除非工作流需要，否则保持本地端口绑定关闭。单独配置对私有网络目标的访问；允许一个域名本身并不意味着批准其私有地址。参阅网络访问要求。

5. 单独配置网页搜索、应用、MCP server、浏览器活动和 Codex Cloud。本地沙箱规则不控制这些活动。

验证

• 向已批准的域名发送请求，并确认请求成功。

• 向未批准的域名发送请求，并确认请求被阻止。

• 向 localhost、私有 IP 和云元数据端点发送请求。确认每个请求都被阻止，除非已明确批准。

• 在 Codex Cloud (Legacy) 中，尝试向允许的域名发送 POST 请求。确认在仅允许 GET、HEAD 和 OPTIONS 时，该请求被阻止。

• 确认代理或网关日志中同时包含允许和拒绝请求的记录。

回滚

将环境恢复为 Off，或恢复此前的域名策略。避免回滚到不受限制的互联网访问。

适用边界

经批准的完全沙箱提权可以绕过本地命令代理。在依赖此限制前，请分别测试普通沙箱命令和经批准的提权命令。

允许的域名仍可能托管提示词注入内容、已被入侵的软件包或不安全的文档。

如果 Codex 需要访问已批准的源代码目录，同时机密信息、.env 文件、SSH 密钥和无关仓库应保持不可访问，请使用此方案。它涵盖限制文件访问，以及减少传递给所启动命令的含凭据环境变量数量。

预期结果

Codex 可以在已批准的源代码目录中工作，但无法读取常见的含机密信息文件，也不会继承大量含凭据的环境变量。

配置

1. 在工作区配置档案中定义拒绝读取模式：

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. 为已知凭据目录、签名密钥、生产配置和相邻仓库添加确切的拒绝访问路径。

3. 在系统 /etc/codex/config.toml 或用户 ~/.codex/config.toml 中，减少传递给所启动命令的环境变量：

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

这是用户可配置的默认值，而非强制要求。它会减少继承的变量，但不会阻止访问凭据文件、辅助程序、Shell 启动内容或其他身份。参阅高级配置。

4. 在管理员管理的 requirements.toml 中，选择受限配置档案，并仅允许使用该配置档案。内置配置档案不会继承其中针对机密文件的拒绝访问规则：

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. 为你的 Cloud 环境选择凭据流程：

   • 在当前 Codex Cloud 中，对于发送至允许的 HTTPS 服务的凭据，请使用 Network secrets。程序接收到的是占位值，代理会在设置和任务期间，为发往端口 443 上已批准目标的请求替换为真实值。原始凭据不会放入本地进程或文件中。直接设置的环境变量可供程序访问。参阅环境变量和网络机密。
   • 在 Codex Cloud (Legacy) 中，机密用于设置阶段的身份验证，并在智能体阶段开始前移除；环境变量则在整个聊天期间保留。参阅 Legacy Cloud 环境。

6. 如果智能体需要身份验证，请使用独立的凭据代理提供短期凭据，并将其权限限定到确切目标和操作。参阅推荐配置。

验证

创建无害的探测文件和变量：

.env.test
test-key.pem
.aws/credentials
.kube/config

然后让 Codex：

• 读取一个普通文件。

• 读取每个探测文件和变量。

• 递归搜索机密信息。

• 输出其命令环境。

• 读取相邻仓库。

预期：普通文件读取成功；禁止访问的文件和相邻仓库仍不可访问，排除的变量未出现在命令环境中。

回滚

恢复此前的配置档案，但在调查工作流故障期间，保留确定需要的机密文件拒绝访问规则。

适用边界

文件系统拒绝访问规则无法移除已粘贴到提示词中、提交到可读源代码中、由连接器返回，或写入模型可访问日志中的机密信息。

如果 git push、部署、数据库迁移和云 CLI 命令等操作需要先获批准再执行，请使用此方案。确定哪些命令应提示审核，哪些必须禁止，然后为这些命令配置规则。

预期结果

敏感命令始终暂停以等待审批，或被禁止，即使模型认为执行这些命令是合适的。

配置

1. 确定哪些命令需要提示审批，哪些应被禁止。

2. 添加管理员强制执行的命令规则：

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

要求中的规则可以要求提示审批或禁止命令，但不能允许命令。参阅托管配置。

3. 对于高风险配置档案，如果 Shell 包装器可能掩盖敏感命令，请向同一个 prefix_rules 数组添加 Shell 包装器条目：

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

Shell 包装器条目会触发较多提示，请有选择地使用。

4. 如果必须由人审批命令，请强制执行以下设置：

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

自动审核改变的是审核者；它并非确定性的安全保障。参阅自动审核。

5. 将 PermissionRequest、工具决策和工具结果事件发送至安全处理管道。

验证

• 运行 git status。预期：不出现审批提示。

• 运行 git push。预期：出现审批提示。

• 运行 terraform apply。预期：出现审批提示。

• 运行 kubectl delete pod test。预期：出现审批提示。

• 运行 rm -rf test-directory。预期：命令被禁止。

• 拒绝一个审批请求。预期：命令不执行，拒绝操作被记录到日志中。

• 重启客户端并重复检查。预期：规则仍被强制执行。

回滚

恢复此前的要求配置包。对于范围过大的词元匹配模式，应缩小其范围，而不是移除整个敏感命令类别。

适用边界

前缀规则并非完整的操作系统策略引擎。请结合沙箱、最小权限操作系统账户、网络限制、云 IAM、分支保护、部署审批和数据库授权。

使用以下单项配置方案： 限制权限配置档案和完全访问权限；保护机密信息和无关仓库；要求敏感命令经过审批。

开发者拥有正当的生产环境访问权限，但你希望 Codex 协助开发，同时避免未经审核的生产环境更改。

• 定义已批准的工作区配置档案，并强制执行允许的配置档案和审批策略。将这些设置作为管理员强制执行的要求下发，防止用户覆盖。

• 使用独立的低权限身份运行 Codex，或在无法访问或获取生产环境写入凭据的环境中运行。开发者可以通过独立的授权工作流保留生产环境访问权限。

• 尽量减少传递给所启动命令的环境变量。如果智能体需要身份验证，请使用独立的凭据代理提供短期凭据，并将其权限限定到确切目标和操作。

• 确定哪些命令需要审批提示，哪些应被禁止。要求由人审批选定的高影响命令，例如 git push、terraform apply、Kubernetes 更改和数据库迁移；禁止绝不能运行的命令。

• 独立于 Codex，持续强制执行生产环境 IAM、分支保护和部署审批。

限制权限配置档案并要求人工审核

在管理员管理的 requirements.toml 中，允许内置的工作区和只读配置档案，并要求需要审批的操作由用户审核：

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

工作区配置档案允许在其沙箱内开展工作区工作；只读配置档案可用于范围更窄的工作。完全访问权限配置档案不在允许列表中。

如果客户端需要明确选择一个兼容配置，请在客户端配置中设置 approval_policy = "on-request"。on-request 允许在需要时显示审批提示；它不会对每条命令都提示审批。为需要审核的操作添加明确规则，并保留独立的生产环境授权。

托管配置档案允许列表要求使用 Codex 0.138.0 或更高版本；对于旧版客户端，请使用并测试文档中说明的旧版沙箱模式要求。

重启每个试点客户端，验证已批准的配置档案可以正常使用，并验证不允许的完全访问权限配置档案会被拒绝。

将 Codex 身份与生产环境凭据分离

在设备管理或开发环境配置系统中，创建专用的 Codex 用户、容器或开发主机，仅授予其访问所需源代码和开发服务的权限。不要将开发者的生产环境凭据文件、令牌辅助程序或钥匙串挂载到该环境中，并防止该身份获取生产环境写入角色。

如果智能体需要访问服务，请配置组织的凭据代理，签发仅限指定开发资源和操作的短期凭据。开发者可以通过独立的授权生产工作流使用其常规身份。

例如，在 AWS IAM 中，打开 Roles，选择 Codex 开发角色，然后在 Permissions 下添加经过审核的内联策略，如下所示，并将账户和角色替换为你自己的值：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

此示例会拒绝代入指定角色的尝试，但不会拒绝代入其他角色的尝试。还应移除直接生产环境权限，限制其他生产环境角色和凭据来源，并审核信任策略和组织级控制措施。

在不更改生产环境的情况下，使用有代表性的开发和生产权限测试开发角色。请参阅 AWS IAM 角色策略示例。

最小化 shell 环境

在用于系统级初始配置的 /etc/codex/config.toml 或用于单个用户的 ~/.codex/config.toml 中，配置启动的命令可以继承哪些环境变量：

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

这是可配置的默认设置，并非强制执行的凭据边界。用户设置、shell 启动脚本或快照、凭据助手以及其他凭据来源仍可能暴露凭据。

在 requirements.toml 中，如果以下可选限制与你的工作流兼容，可用它们禁用登录 shell 和 shell 快照：

allow_login_shell = false

[features]
shell_snapshot = false

请先试用这些设置，因为某些工作流依赖登录 shell 的初始化。

使用匹配筛选条件的无害合成变量启动 Codex，并检查所启动命令的环境；如果禁用了登录 shell，还应验证登录 shell 请求会被拒绝。另行验证执行身份无法访问真实的生产凭据。请参阅 Shell 环境策略。

对选定的高影响命令请求审批

为组织使用的命令添加强制要求规则。例如：

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

对于绝不能运行的命令，使用 forbidden；根据实际部署和迁移工具替换或添加匹配模式。

这些规则匹配命令前缀，无法涵盖所有等效操作。请分别测试绝对路径、包装脚本、不同的参数顺序、其他客户端和其他工具。

在一次性测试目标上，运行普通命令，请求执行一项列出的操作，拒绝审批请求，并验证该操作未执行。请参阅强制执行命令规则。

在 Codex 外部强制执行仓库和部署审批

在源代码管理平台中，保护 main 等生产分支：要求变更经过审查，并获得必要的审批且通过状态检查，同时审查哪些角色可以绕过这些要求。在相关部署系统中配置部署审批，并在数据库本身配置数据库权限。

使用一次性测试仓库，验证经过审查的变更可以正常应用，且未经授权的直接推送会被拒绝。无论操作是否通过 Codex 请求，这些控制措施都适用。

验证

在一次性测试目标上：

• 运行普通的工作区任务。预期结果：任务成功。

• 尝试执行一条有代表性的敏感命令，并拒绝审批请求。预期结果：被拒绝的命令不会运行。

• 验证 Codex 身份无法获得生产环境的写入权限。

• 重启客户端并重复测试。

边界

前缀规则并不是完整的操作系统策略引擎。请将其与沙箱、最小权限操作系统账户、网络限制、云 IAM、分支保护、部署审批和数据库授权结合使用。

使用以下配置方案： 保护密钥和无关仓库；限制网络目标；仅允许获批的 MCP server；要求敏感命令获得审批。

开发者使用 Codex 处理内部仓库，而你希望降低代码被发送到公共仓库、公开代码片段或其他未经批准的目标的风险。

• 为已知凭据目录和无关仓库添加精确的拒绝访问路径，并尽量减少传递给所启动命令的环境变量。

• 需要为智能体提供互联网访问时，使用范围严格的获批域名允许列表。仅允许获批的 MCP server名称和身份，并要求对选定的发布命令进行审查，或拒绝这些命令，例如 git push。

• 使用适合你所在组织的源代码管理钩子和权限、公共仓库与代码片段策略，以及数据丢失防护控制措施。

拒绝访问无关仓库和凭据文件

在管理员管理的 requirements.toml 中，添加本地智能体不得读取的精确路径：

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

将示例替换为受管设备上实际存在的路径。这项受管拒绝规则适用于所有允许的权限配置档案；仅在某个自定义配置档案中配置的拒绝规则，无法保护选择其他配置档案的用户。优先使用精确的已知路径，并在所需的目录深度测试所有 glob 模式。

在原生 Windows 上，受管 deny_read 涵盖直接文件工具，但其本身无法阻止 shell 子进程读取；还应使用操作系统身份和文件访问控制列表。

在被拒绝访问的位置创建无害的探测文件。在每个允许的配置档案下，验证直接读取和通过 shell 读取这些文件的操作均被拒绝，并验证可以读取获批的源文件。请参阅受管拒绝读取要求。

尽量减少包含凭据的 shell 变量

在 /etc/codex/config.toml 或 ~/.codex/config.toml 中，严格限定继承的环境变量：

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

此设置会减少继承的变量，但用户可以自行配置，且它无法阻止访问凭据文件、凭据助手、shell 启动内容或其他身份。

在适当情况下，管理员还可以将以下限制添加到 requirements.toml 中，并先行试用，以评估它们对开发者工作流的影响：

allow_login_shell = false

[features]
shell_snapshot = false

使用合成的探测变量和单独的最小权限执行身份进行测试。不要使用真实凭据。请参阅 Shell 环境策略。

仅允许本地命令访问获批的网络目标

如果本地沙箱命令需要网络访问，将以下配置档案设置和受管代理设置一并合并到 requirements.toml 中，并将域名替换为获批的端点：

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

启用网络的配置档案为沙箱命令提供网络通路，而受管代理会限制其访问目标。请将两者一起部署；如果启用网络的配置档案没有配合预期的受管代理，就不会施加相同的目标限制。如果不需要互联网访问，请保持禁用网络访问。

不要将规范的 domains 表与旧版 allowed_domains 或 denied_domains 设置混用；请迁移并测试现有策略。

重启客户端，验证获批端点可以访问，且未经批准的端点会被阻止。

这些设置属于实验性功能；请验证操作系统和客户端支持情况，如果获批主机解析为私有地址，还需单独配置私有网络访问。获批的完整沙箱提权可以绕过命令代理。

这项针对本地命令的网络控制本身不涵盖网页搜索、应用、MCP server、浏览器活动或云环境，这些都需要单独的策略。获批的托管域名也可能包含公共仓库或公开代码片段，因此仅靠目标允许列表无法保护内容。请参阅网络访问要求。

单独配置云环境网络

在当前的 Codex Cloud 界面中，打开环境配置。保持关闭允许 Codex 访问互联网。如果需要互联网访问，开启该选项并选择仅自定义域名，在额外允许的域名 下添加所需的精确主机名，然后保存配置，发布或重新发布环境，并测试一个新任务。

单独审查服务的身份验证和功能。

旧版 Codex Cloud 使用单独的、按环境配置的智能体互联网设置，可控制允许的域名和 HTTP 方法；设置脚本有自己的访问行为。

请测试你实际使用的环境版本。请参阅连接到服务和旧版互联网设置。

限制 MCP server并在 Git 推送前请求审批

在 requirements.toml 中仅允许获批的本地 MCP server身份。例如：

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

在用户或受管默认 config.toml 中单独配置实际服务器，使用匹配的名称和 URL，以及服务器要求的身份验证方式：

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

这项强制要求仅允许匹配的服务器，并不会创建服务器。请审查该服务器自身的访问权限和工具。

验证获批服务器可以连接，且名称或 URL 不同的服务器不被允许。

添加受管命令规则，在执行有代表性的发布命令前请求审查：

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

如果必须由人员审查，请同时将 allowed_approval_policies = ["on-request"] 和 allowed_approvals_reviewers = ["user"] 配置为顶层强制要求。

拒绝一次测试推送，并确认其未运行。

前缀匹配无法涵盖所有包装脚本、API 客户端、应用或其他发布途径。

使用源代码管理和 DLP 控制措施限制公开发布

在源代码管理平台支持的情况下，限制创建公共仓库，并限制哪些人可以更改仓库可见性。审查特权用户的绕过权限。另行检查个人账户、代码片段、外部组织和令牌访问：组织设置无法管控所有目标。

在相关仓库中，要求变更经过审查，并审查分支保护和绕过权限。

在组织的 DLP 控制台中，针对敏感源代码内容以及 DLP 产品实际涵盖的上传或仓库渠道配置试点策略；将操作设置为阻止，并使用无害的合成标记进行测试。

如果源代码管理平台支持服务器端控制，请为接收推送的仓库配置并强制执行经过审查的钩子。

使用获授权的测试目标，并在任何发布之前确认阻止机制有效。

验证

• 创建无害的探测文件，并确认读取被拒绝访问的文件的尝试均失败。

• 如果启用了网络访问，检查获批目标可以访问，且未经批准的目标会被阻止；否则，验证网络请求会被阻止。

• 使用无害标记和一次性测试账户或目标，验证有代表性的公开发布尝试会在发布前被阻止。

边界

允许的域名仍可能托管公开内容。请单独配置网页搜索、应用、MCP server、浏览器活动和 Codex Cloud；本地沙箱规则无法控制它们。

使用以下配置方案： 限制权限配置档案和 Full Access；仅允许获批的 MCP server；限制网络目标；保护密钥和无关仓库；要求敏感命令获得审批。

你希望在 Codex 处理仓库或用户更改本地配置时，约束 Codex 的限制仍然有效。

• 将受支持的权限、审批、MCP、网络和命令限制设为管理员强制执行的要求并下发。

• 将钩子脚本安装到管理员管理的目录中，如果需要忽略用户、项目和插件钩子，则仅使用受管钩子。

• 使用操作系统和设备管理控制措施保护策略文件及配置分发路径。运行 Codex 时，不授予其更改这些保护措施所需的权限。

• 审查范围内每个客户端和环境的实际生效配置。

强制执行允许的配置档案、审批、服务器身份和命令

将经过审查的设置合并到管理员管理的 requirements.toml 中，而不是依赖用户或仓库中可编辑的设置。例如：

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

此示例允许两个配置档案，要求在需要审批时由人工审查，允许匹配的 MCP 身份，并对特定命令前缀请求审批。

单独配置 MCP server本身，并添加组织的其他敏感命令模式。根据需要添加全局文件限制和网络限制；强制要求可以约束受支持的设置，但无法取代 Codex 外部的身份、服务和目标控制措施。

受管配置档案允许列表要求 Codex 0.138.0 或更高版本。

在试点客户端上，尝试选择不允许的配置档案、更改受限制的用户或项目设置，以及使用不在允许列表中的 MCP 身份；验证每项操作均被拒绝，或在重启后仍受到约束。拒绝一次测试命令审批，并验证该命令未运行。

添加受管文件系统和网络限制

要在所有允许的配置档案下拒绝访问敏感本地文件，请将以下表添加到 requirements.toml 中，并将示例替换为组织的路径：

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

如果沙箱中的本地命令需要网络访问，请同时定义允许的、启用网络的配置档案和受管目标：

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

选择此配置档案策略来替代前面的 :workspace 默认设置，或有意合并两个配置档案名称；不要粘贴重复的键或表。如果命令不需要网络，请保持禁用网络。

使用无害文件验证精确的拒绝访问路径，并验证获批和未经批准的目标。

在原生 Windows 上，还应使用文件访问控制列表，因为仅靠受管 deny_read 无法涵盖 shell 子进程读取。

本地命令的网络设置无法管控其他客户端、应用、连接器或云端执行。

安装并强制执行管理员管理的钩子

请管理员将经过审查的钩子程序安装到由 root 管理的目录中，例如 /etc/codex/hooks/pre_tool_use_policy.py，并阻止 Codex 用户更改该文件或其目录。在 requirements.toml 中启用钩子，并忽略用户、项目、会话和插件钩子：

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

这项强制要求会注册钩子，但不会安装它。如需进行本地 macOS 集成测试，请将以下内容保存为 pre_tool_use_policy.py，并请管理员使用下方命令安装。

它只会阻止合成标记；在依赖它之前，请将其替换为经过审查的组织专用策略。确认目标上存在 /usr/bin/python3，并根据需要调整解释器路径：

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

重启本地客户端，然后：

• 确认无害的 Bash 命令可以运行。

• 确认包含 CODEX_HOOK_TEST_DENY 的命令会被阻止。

• 验证 Codex 用户无法更改策略及其依赖项。

allow_managed_hooks_only 会跳过所有非受管的用户、项目、会话和插件钩子，并可能影响其他工作流。

Bash 匹配器无法涵盖所有工具，也无法涵盖之后提供给现有进程的所有输入；错误、超时或格式不正确的钩子响应可能会让工具调用继续执行。

由云端编排的 Work 使用不同的受支持钩子处理程序。请保留独立的操作系统和服务保护措施。请参阅受管钩子和钩子行为。

保护策略及其分发流程

在 macOS 上，管理员可以将经过审查和合并的强制要求文件部署到 root 所有的父目录中，并阻止 Codex 用户写入该文件：

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

在 Linux 上，使用适当的管理员组；在 Windows 上，使用管理员管理的访问控制列表保护 ProgramData 目录和文件。限制哪些人可以更改 MDM 或云策略，审查变更，并保留回滚副本。

使用非管理员试点账户，验证该账户无法修改策略、父目录或受管钩子程序；尝试更宽松的用户或项目设置，重启 Codex，并验证强制执行的行为仍然有效。

测试范围内的每个客户端和环境，不要假定所有客户端都加载相同的策略。

验证

使用非管理员测试身份：

• 尝试编辑受管策略。预期结果：无法更改受管文件。

• 尝试通过用户或项目配置放宽限制。预期结果：更宽松的设置被拒绝或仍受到约束。

• 重启客户端，验证限制仍然有效。

边界

拥有足够主机管理员权限的用户或智能体可能能够更改外围保护措施。仅靠用户可编辑的设置无法替代管理员管理的强制要求。