托管配置

企业管理员可以通过两种方式控制本地 Codex 的行为：

• 要求：管理员强制执行的约束，用户无法覆盖。
• 托管默认值：Codex 启动时应用的初始值。用户仍可在会话期间更改设置；Codex 会在下次启动时重新应用托管默认值。

管理员强制要求 (requirements.toml)

要求用于约束安全敏感设置（批准策略、批准审查者、自动审查策略、沙盒模式、Web 搜索模式、托管挂钩，以及可选地限制用户可以启用哪些 MCP 服务器）。在解析配置时（例如来自 config.toml, 配置文件，或 CLI 配置覆盖），如果某个值与强制规则冲突，Codex 将回退到兼容的值并通知用户。如果您配置了 mcp_servers 允许列表，Codex 仅在 MCP 服务器的名称和身份均与已批准的条目匹配时才启用它；否则，Codex 会将其禁用。

要求也可以约束 功能标志 通过 [features] 表，位于 requirements.toml。请注意，功能并不总是安全敏感的，但企业可以根据需要锁定值。省略的键将不受约束。

有关确切的键列表，请参见 requirements.toml 《配置参考》中的部分.

位置与优先级

Codex 按以下顺序应用需求层（每个字段以先设定的为准）：

1. 云托管需求（ChatGPT Business 或 Enterprise）
2. 通过以下方式配置的 macOS 托管偏好设置 (MDM)： com.openai.codex:requirements_toml_base64
3. 系统 requirements.toml (/etc/codex/requirements.toml 在 Unix 系统上（包括 Linux/macOS），或者 %ProgramData%\OpenAI\Codex\requirements.toml 在 Windows 上）

跨层级合并时，Codex 会按字段合并要求：如果较早的层设置了某个字段（包括空列表），则较晚的层不会覆盖该字段，但较低的层仍可填充尚未设置的字段。

为了向后兼容，Codex 还会解释旧版 managed_config.toml 字段 approval_policy and sandbox_mode 作为要求（仅允许该单一值）。

云端托管要求

当您使用 ChatGPT 商业版或企业版计划登录时，Codex 还可以从 Codex 服务获取管理员强制要求。这是另一个 requirements.toml兼容要求的来源。这适用于所有 Codex 界面，包括 CLI、App 和 IDE 扩展。

配置云端托管要求

前往 Codex 托管配置页面.

使用与以下文件相同的格式和键创建新的托管要求文件： requirements.toml.

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

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entrypoints" },
]

保存配置。保存后，更新后的托管要求将立即应用于匹配的用户。有关更多示例，请参见 示例 requirements.toml.

将要求分配给各个组

管理员可以为不同的用户组配置不同的托管需求，也可以设置默认的回退需求策略。

如果用户匹配到多个特定组的规则，则应用第一条匹配的规则。Codex 不会用后续匹配的组规则来填充未设置的字段。

例如，如果第一条匹配的组规则仅设置 allowed_sandbox_modes = ["read-only"] 而后续匹配的组规则设置 allowed_approval_policies = ["on-request"]，Codex 仅应用第一个匹配的组规则，并且不会填充 allowed_approval_policies from the later rule.

Codex 如何在本地应用云托管需求

当用户启动 Codex 并使用 Business 或 Enterprise 计划的 ChatGPT 登录时，Codex 会尽最大努力应用托管需求。Codex 首先会检查是否存在有效且未过期的本地托管需求缓存条目，如果可用则使用它。如果缓存缺失、过期、损坏，或者与当前的身份验证身份不匹配，Codex 会尝试（通过重试）从服务获取托管需求，并在成功时写入新的已签名缓存条目。如果没有有效的缓存条目且获取失败或超时，Codex 将在没有托管需求层的情况下继续运行。

在完成缓存解析后，Codex 会将托管需求作为上述常规需求分层的一部分来执行。

示例 requirements.toml

此示例阻止 --ask-for-approval never and --sandbox danger-full-access (包括 --yolo):

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

按主机覆盖沙箱需求

使用 [[remote_sandbox_config]] 当一项托管策略需要在不同主机上应用不同的沙箱需求时使用。例如，您可以对笔记本电脑保持更严格的默认设置，同时在匹配的开发机或 CI 运行器上允许工作区写入。特定主机的条目当前会覆盖 allowed_sandbox_modes only:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Codex 会将每个 hostname_patterns 条目与尽力解析出的主机名进行比对。它优先使用完全限定域名（在可用时），并回退到本地主机名。匹配不区分大小写； * 匹配任意字符序列，而 ? 匹配单个字符。

The first matching [[remote_sandbox_config]] 条目在同一需求来源中胜出。如果没有条目匹配，Codex 将保留顶级 allowed_sandbox_modes。主机名匹配仅用于策略选择；请勿将其视为已验证设备的证明。

您还可以限制网页搜索模式：

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] 仅允许 "disabled"。例如， allowed_web_search_modes = ["cached"] 即使在以下模式也阻止实时网页搜索： danger-full-access sessions.

配置网络访问要求

使用 [experimental_network] in requirements.toml 当管理员需要集中定义网络访问要求时。这些要求独立于用户的 features.network_proxy 开关：即使没有该功能标志，他们也可以配置沙盒网络，但当处于活动状态的沙盒关闭网络时，它们不会授予命令网络访问权限。

experimental_network.enabled = true
experimental_network.dangerously_allow_all_unix_sockets = true
experimental_network.allow_local_binding = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

使用 experimental_network.managed_allowed_domains_only = true 仅当您同时定义管理员所有的 allowed_domains 并希望该允许列表具有排他性时。如果是 true 在没有托管允许规则的情况下，用户添加的域允许规则将不会保持有效。

域语法、本地/私有目标规则、拒绝优先于允许的行为以及 DNS 重绑定限制与中所描述的沙盒网络行为相同 智能体审批与安全.

推荐设置：

你也可以固定 功能标志 对于接收托管的用户， requirements.toml:

[features]
personality = true
unified_exec = false

# Disable specific Codex feature surfaces when needed.
browser_use = false
in_app_browser = false
computer_use = false

请使用来自的特性规范键 config.toml’s [features] 表格。Codex 会规范化生成的特性集以满足这些固定，并拒绝冲突的写入操作，写入目标是 config.toml 或配置文件中的特性设置。

• in_app_browser = false 禁用应用内浏览器窗格。
• browser_use = false 禁用 Browser Use 和 Browser Agent 可用性。
• computer_use = false 禁用 Computer Use 可用性及相关的安装或设置流程。

如果省略，在遵循常规客户端、平台和发布可用性的前提下，这些功能将被策略允许。

配置自动审查策略

使用 allowed_approvals_reviewers 以要求或允许自动审查。将其设置为 ["auto_review"] 以要求自动审查，或者包含 "user" 当用户可以选择手动批准时。

设置 guardian_policy_config 以替换自动审查策略中特定租户的部分。Codex 仍使用内置的审查者模板和输出约定。托管 guardian_policy_config 优先于本地 [auto_review].policy.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

强制执行拒绝读取 (deny-read) 要求

管理员可以通过以下方式拒绝精确路径或 glob 模式的读取： [permissions.filesystem]。用户无法通过本地配置削弱这些要求。

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

当存在拒绝读取要求时，Codex 会将本地沙盒模式限制为 read-only or workspace-write 以便 Codex 可以强制执行它们。在原生 Windows 上，托管 deny_read 应用于直接文件工具；shell 子进程的读取不使用此沙盒规则。

从需求强制执行托管钩子

管理员还可以直接在 requirements.toml值。使用 [hooks] 中定义托管生命周期钩子，用于钩子配置本身，并将 managed_dir 指向你的 MDM 或端点管理工具安装引用脚本的目录。

若要对本地已禁用钩子的用户强制执行托管钩子，请固定 [features].hooks = true 以及 [hooks]。要跳过用户、项目、会话和插件钩子，同时仍允许托管钩子，请设置 allow_managed_hooks_only = true.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

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

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Notes:

• Codex 将强制执行来自以下位置的钩子配置： requirements.toml, 但它不会分发其中的脚本 managed_dir.
• 通过你的 MDM 或设备管理解决方案单独分发这些脚本。
• 托管的 hook 命令应引用已配置托管目录下的脚本绝对路径。
• allow_managed_hooks_only = true 跳过来自用户、项目、会话和插件来源的 hooks，但仍会加载来自 requirements.toml 和其他托管配置层。

从需求中执行命令规则

管理员还可以通过以下方式强制执行限制性命令规则 requirements.toml 使用 [rules] 表。这些规则将与常规的 .rules 文件合并，并且依然采用限制最严格的决策。

与 .rules，要求规则必须指定 decision，并且该决定必须为 "prompt" or "forbidden" （不 "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

要限制 Codex 可以启用的 MCP 服务器，请添加一个 mcp_servers 已批准列表。对于 stdio 服务器，匹配 command；对于可流式传输的 HTTP 服务器，匹配 url:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

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

If mcp_servers 存在但为空，Codex 会禁用所有 MCP 服务器。

托管默认值（managed_config.toml)

托管默认值会合并在用户的本地配置之上， config.toml 并且优先于任何 CLI --config 覆盖，并在 Codex 启动时设置起始值。用户仍然可以在会话期间更改这些设置；Codex 会在下次启动时重新应用托管默认值。

请确保您的托管默认值满足您的要求；Codex 会拒绝不允许的值。

优先级与分层

Codex 按以下顺序组装有效配置（顶层覆盖底层）：

• 托管偏好设置 (macOS MDM；最高优先级)
• managed_config.toml (系统/托管文件)
• config.toml (用户基础配置)

CLI --config key=value 覆盖应用于基础配置，但托管层会覆盖它们。这意味着，即使您提供了本地标志，每次运行也会从托管默认值开始。

云托管要求会影响要求层（而非托管默认值）。有关优先级，请参阅上文的“管理员强制要求”部分。

位置

• Linux/macOS (Unix)： /etc/codex/managed_config.toml
• Windows/non-Unix: ~/.codex/managed_config.toml

如果文件缺失，Codex 将跳过托管层。

macOS 托管偏好设置 (MDM)

在 macOS 上，管理员可以推送一个设备配置文件，在以下位置提供 base64 编码的 TOML 负载：

• 偏好设置域： com.openai.codex
• Keys:
  • config_toml_base64 （托管默认值）
  • requirements_toml_base64 （要求）

Codex 将这些“托管偏好设置”负载解析为 TOML。对于托管默认值（config_toml_base64），托管偏好设置具有最高优先级。对于要求（requirements_toml_base64），优先级遵循上述云托管要求的顺序。相同的要求端 [features] 表适用于 requirements_toml_base64;在那里也使用规范的功能键。

MDM 设置工作流

Codex 遵循标准的 macOS MDM 负载，因此您可以使用以下工具分发设置： Jamf Pro, Fleet, or Kandji。轻量级部署如下所示：

1. 构建托管的 payload TOML 并使用 base64 （无换行）进行编码。
2. 将该字符串放入您的 MDM 配置文件中的 com.openai.codex 域，位于 config_toml_base64 （托管默认值）或 requirements_toml_base64 （要求）下。
3. 推送配置文件，然后要求用户重启 Codex 并确认启动配置摘要反映了托管值。
4. 在撤销或更改策略时，请更新托管 payload；CLI 将在下一次启动时读取刷新后的偏好设置。

避免在 payload 中嵌入机密或高频更改的动态值。请将托管 TOML 视同变更控制下的任何其他 MDM 设置。

示例 managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

推荐的防护措施

• 在适合工作流的地方，优先选择 workspace-write 为大多数用户配置审批；仅对受控容器保留完全访问权限。
• 保持 network_access = false 除非您的安全审查允许收集器或您工作流所需的域名，否则请使用
• 使用托管配置来锁定 OTel 设置（导出器、环境），但请保持 log_user_prompt = false 除非您的策略明确允许存储提示词内容。
• 定期审核本地 config.toml 与托管策略之间的差异以发现配置偏移；托管层应优先于本地标志和文件生效。