Codex Managed Config | 企业默认与强制规则

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

强制规则（Requirements）：管理员规定哪些值可以使用，用户不能覆盖
托管默认值（Managed defaults）：Codex 启动时先采用这些默认值。用户在当前会话中仍可修改，但下次启动时会重新回到管理员设定的默认值

管理员强制规则（`requirements.toml`）

requirements.toml 用来限制安全相关设置，例如 approval_policy、approvals_reviewer、自动评审策略、sandbox_mode、Web 搜索模式、托管钩子，以及允许启用哪些 MCP server。Codex 在汇总配置时，例如读取 config.toml、profile 或 CLI 覆盖参数，如果发现某个值和强制规则冲突，就会自动改用符合要求的值，并提示用户。

如果你为 mcp_servers 配置了允许列表，只有当服务端的名称和身份信息都与允许项匹配时，Codex 才会启用它；否则会将其禁用。

你也可以通过 requirements.toml 的 [features] 表固定功能开关（feature flags）的取值。功能开关不一定都与安全相关，但如果企业希望统一行为，也可以在这里锁定。没有写出的键不会受到限制。

完整键列表请参见配置参考中的 requirements.toml。

位置与优先级

Codex 会按下面的顺序读取并应用强制规则；对同一个字段来说，越靠前优先级越高：

云端托管强制规则（ChatGPT Business 或 Enterprise）
通过 com.openai.codex:requirements_toml_base64 下发的 macOS 托管偏好设置（managed preferences，MDM）
系统级 requirements.toml，例如 Unix 系统（包括 Linux / macOS）上的 /etc/codex/requirements.toml，或 Windows 上的 %ProgramData%\OpenAI\Codex\requirements.toml

不同来源会按字段合并。如果更高优先级的一层已经写了某个字段，即使它是空列表，后面的层也不能再改这个字段；但仍然可以补充那些尚未设置的字段。

为了兼容旧版本，Codex 也会把旧式 managed_config.toml 里的 approval_policy 和 sandbox_mode 视为强制规则，也就是只允许这一个取值。

云端托管强制规则

当用户用 ChatGPT 账号登录 Business 或 Enterprise 计划时，Codex 还可以从服务端获取管理员设置的强制规则。这一层与 requirements.toml 兼容，并会同时作用于 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 示例。

把强制规则分配给用户组

管理员可以为不同的用户组设置不同的托管强制规则，也可以配置一条默认规则作为兜底。

如果某个用户同时匹配多条分组规则，只会采用第一条命中的规则。后面命中的规则不会再补齐前面没写的字段。

例如，如果第一条命中的规则只设置了 allowed_sandbox_modes = ["read-only"]，而后面另一条命中的规则设置了 allowed_approval_policies = ["on-request"]，那么 Codex 只会应用第一条规则，不会再从后面的规则补充 allowed_approval_policies。

Codex 如何在本地应用云端托管强制规则

当用户启动 Codex，并用 ChatGPT 登录 Business 或 Enterprise 计划时，Codex 会尽可能应用这层云端强制规则。它会先检查本地是否已有有效、未过期的缓存；如果有，就直接使用。如果缓存缺失、过期、损坏，或和当前登录身份不匹配，Codex 会尝试从服务端重新拉取，并在成功后写入新的签名缓存。

如果本地没有可用缓存，同时拉取失败或超时，Codex 仍会继续运行，只是不会应用这一层云端强制规则。

缓存处理完成后，这一层规则会按照上面介绍的优先级正常生效。

`requirements.toml` 示例

下面这个示例会阻止使用 --ask-for-approval never 和 --sandbox danger-full-access，其中也包括 --yolo：

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

按主机覆盖沙箱强制规则

当同一份托管策略需要在不同主机上应用不同的沙箱要求时，可以使用 [[remote_sandbox_config]]。例如，你可以为笔记本保留更严格的默认值，同时允许匹配的 dev box 或 CI runner 使用 workspace-write。主机级条目当前只会覆盖 allowed_sandbox_modes：

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 条目与尽力解析出的主机名比较。可用时优先使用完整限定域名，否则回退到本地主机名。匹配不区分大小写；* 匹配任意字符序列，? 匹配单个字符。

在同一个 requirements 来源中，第一个命中的 [[remote_sandbox_config]] 条目生效。如果没有条目命中，Codex 会保留顶层的 allowed_sandbox_modes。host name 匹配只用于策略选择，不应把它当作已认证的设备证明。

你也可以限制 Web 搜索模式：

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

allowed_web_search_modes = [] 表示只允许 "disabled"。

例如，allowed_web_search_modes = ["cached"] 会禁止实时 Web 搜索，即使用户当前会话运行在 danger-full-access 模式下也一样。

配置网络访问要求

当管理员需要集中定义网络访问要求时，可以在 requirements.toml 中使用 [experimental_network]。这些要求独立于用户侧的 features.network_proxy 开关：它们可以在不启用该功能开关的情况下配置 sandboxed networking，但如果当前激活的沙箱本身关闭了命令联网，它们不会授予命令网络访问。

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",
]

只有在同时定义了管理员管理的 allowed_domains，并且希望这个 allowlist 成为唯一有效列表时，才使用 experimental_network.managed_allowed_domains_only = true。如果它为 true 但没有托管 allow 规则，用户新增的域名 allow 规则也不会继续生效。

域名语法、本地 / 私有目的地规则、deny 优先于 allow 的行为，以及 DNS rebinding 限制，都与智能体审批与安全中描述的 sandboxed networking 行为一致。

固定功能开关

你也可以为接收托管 requirements.toml 的用户固定功能开关（feature flags）的取值：

[features]
personality = true
unified_exec = false

# 需要时禁用特定 Codex 功能界面。
browser_use = false
in_app_browser = false
computer_use = false

这里要使用 config.toml 的 [features] 表中定义的标准键名。Codex 会确保最终生效的功能开关符合这些固定值，并拒绝把冲突设置写入 config.toml 或配置档案级配置。

in_app_browser = false 会禁用 app 内浏览器面板。
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 要求

管理员可以通过 [permissions.filesystem] 拒绝读取精确路径或 glob 模式。用户不能用本地配置放宽这些强制要求。

[permissions.filesystem]
deny_read = [
  # 值可以是绝对路径...
  "/**/*.env",
  # ...也可以用 `~` 表示相对于 $HOME/%USERPROFILE%。
  "~/.ssh",
  # 但不允许使用以 `./` 开头的相对路径。
]

配置了读取拒绝（deny-read）强制规则后，Codex 会将本地沙箱模式限定为 read-only 或 workspace-write，这样 Codex 才能真正执行这些限制。在原生 Windows 上，管理员下发的 deny_read 只适用于直接操作文件的工具；通过 shell 子进程发起的读取不会套用这项沙箱规则。

通过 requirements 强制执行托管钩子

管理员也可以直接在 requirements.toml 中定义托管生命周期钩子。使用 [hooks] 编写钩子配置本身，并让 managed_dir 指向你的 MDM 或终端管理工具安装相关脚本的目录。

若要即使用户在本地关闭 hooks 也强制执行托管 hooks，请把 [features].hooks = true 与 [hooks] 一起固定下来。

[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"
timeout = 30
statusMessage = "Checking managed Bash command"

注意事项：

Codex 会强制执行 requirements.toml 中的钩子配置，但不会分发 managed_dir 中的脚本。
请用 MDM 或设备管理方案单独分发这些脚本。
托管钩子命令应引用配置的托管目录下的绝对脚本路径。

通过 requirements 强制执行命令规则

管理员还可以在 requirements.toml 的 [rules] 表里写入更严格的命令规则。这些规则会和普通 .rules 文件一起生效，最后仍以限制更严格的结果为准。

和 .rules 不同，这里的每条规则都必须显式写出 decision，而且只能是 "prompt" 或 "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." },
]

如果你要限制用户可以启用哪些 MCP servers，可以为 mcp_servers 配置允许列表。对于 stdio server，要匹配 command；对于 streamable HTTP server，要匹配 url：

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

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

如果 mcp_servers 存在但为空，Codex 会禁用所有 MCP servers。

托管默认值（`managed_config.toml`）

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 / 非 Unix：~/.codex/managed_config.toml

如果文件不存在，Codex 会跳过这一层托管配置。

macOS 托管偏好设置（MDM）

在 macOS 上，管理员可以通过设备配置描述文件下发 base64 编码的 TOML 内容：

偏好设置域：com.openai.codex
键：
- config_toml_base64（托管默认值）
- requirements_toml_base64（强制规则）

Codex 会把这些托管偏好设置按 TOML 解析。对于托管默认值 config_toml_base64，这一层拥有最高优先级。对于强制规则 requirements_toml_base64，优先级则遵循上文“云端托管强制规则”的顺序。

在 requirements_toml_base64 里同样可以使用 [features] 表，这里也要使用标准键名。

MDM 设置流程

Codex 兼容标准 macOS MDM 配置格式，所以你可以用 Jamf Pro、Fleet 或 Kandji 这类工具统一下发设置。一个轻量的部署流程通常如下：

写好要下发的 TOML，再用 base64 编码，编码结果不要换行。
把编码后的字符串放进 MDM 配置描述文件的 com.openai.codex 域，写到 config_toml_base64（托管默认值）或 requirements_toml_base64（强制规则）。
下发配置描述文件后，让用户重启 Codex，并确认启动时显示的配置摘要已经反映管理员设置的值。
如果需要撤销或调整策略，更新这份托管内容；CLI 会在下次启动时读取新的偏好设置。

不要在这份内容里写入密钥或频繁变动的动态值。应把这份托管 TOML 当作正式受控配置来管理，和其他需要走变更流程的 MDM 设置保持同样的管理方式。

`managed_config.toml` 示例

# 使用较保守的默认值
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # 默认关闭网络，除非明确允许

[otel]
environment = "prod"
exporter = "otlp-http"            # 指向你的日志采集端
log_user_prompt = false            # 不记录用户提示词内容
# exporter 的详细配置写在对应的 exporter 表中；参见上方监控与遥测说明

最近搜索

推荐搜索

托管配置

管理员强制规则（`requirements.toml`）

位置与优先级

云端托管强制规则

配置云端托管强制规则

把强制规则分配给用户组

Codex 如何在本地应用云端托管强制规则

`requirements.toml` 示例

按主机覆盖沙箱强制规则

配置网络访问要求

固定功能开关

配置自动评审策略

强制执行 deny-read 要求

通过 requirements 强制执行托管钩子

通过 requirements 强制执行命令规则

托管默认值（`managed_config.toml`）

优先级与叠加关系

位置

macOS 托管偏好设置（MDM）

MDM 设置流程

`managed_config.toml` 示例

推荐防护栏

管理员强制规则（requirements.toml）

位置与优先级

云端托管强制规则

配置云端托管强制规则

把强制规则分配给用户组

Codex 如何在本地应用云端托管强制规则

requirements.toml 示例

按主机覆盖沙箱强制规则

配置网络访问要求

固定功能开关

配置自动评审策略

强制执行 deny-read 要求

通过 requirements 强制执行托管钩子

通过 requirements 强制执行命令规则

托管默认值（managed_config.toml）

优先级与叠加关系

位置

macOS 托管偏好设置（MDM）

MDM 设置流程

managed_config.toml 示例

推荐防护栏

管理员强制规则（`requirements.toml`）

`requirements.toml` 示例

托管默认值（`managed_config.toml`）

`managed_config.toml` 示例