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

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

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

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

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

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

对于 Codex 0.138.0 或更新版本，优先使用权限配置档案，也就是通过 allowed_permission_profiles 搭配托管的 default_permissions 管理权限。只有仍在使用 sandbox_mode 的旧部署，才继续使用 allowed_sandbox_modes。

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

位置与优先级

Codex 会按下面的顺序检查 requirements 来源。如果同一设置出现多次，第一处取值生效：

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

Codex 会从上到下检查这些来源。对于普通设置和列表，它会使用找到的第一个值。更低优先级的来源仍可以补充前面来源没有设置的项目。

表格会按单个条目合并。对于 allowed_permission_profiles，较低优先级来源可以添加较高优先级来源没有提到的配置档案名称。如果两个来源设置了同一个配置档案名称，前面的来源生效。

为了兼容旧版本，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"]

禁用 Appshots

如果要为受管理用户禁用 Appshots，请设置顶层 allow_appshots requirement：

allow_appshots = false

Codex 只会把 allow_appshots = false 视为禁用 Appshots。如果省略这个键，Appshots 不会受到 requirements 约束，仍按正常产品可用性检查决定是否可用。通过 configRequirements/read 读取有效 requirements 的 app-server 客户端会收到同样的限制，也就是 allowAppshots；省略或设为 null 的 allowAppshots 不会禁用 Appshots。

禁用设备远程控制

如果要为受管理用户禁用设备远程控制，请设置顶层 allow_remote_control requirement：

allow_remote_control = false

Codex 只会把 allow_remote_control = false 视为禁用设备远程控制。如果省略这个键，设备远程控制不会受到 requirements 约束，仍按正常产品可用性检查决定是否可用。这个 requirement 不会禁用 SSH 远程连接。

控制可用权限配置档案

使用 allowed_permission_profiles 可以控制用户能选择哪些内建和自定义权限配置档案。它相当于权限配置档案版本的 allowed_sandbox_modes；请根据用户实际选择权限的方式，使用对应的允许列表。

权限配置档案允许列表要求 Codex 0.138.0 或更新版本。Codex 0.137.0 及更早版本会忽略 allowed_permission_profiles 和托管的 default_permissions。

只有在所有受管理客户端都运行支持版本后，才使用下面的权限配置档案示例。不要在 fleet 升级完成前部署托管自定义配置档案。

当 [allowed_permission_profiles] 表存在时，它就是完整的允许列表。设为 true 的配置档案会被允许；省略或设为 false 的配置档案会被拒绝，包括未来 Codex 版本新增的内建配置档案。

允许标准配置档案

下面的策略允许只读和工作区访问，但不允许完全访问：

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# 省略 ":danger-full-access"，因此它会被拒绝。

添加托管的最小权限默认值

管理员可以在同一个 requirements 来源中定义自定义配置档案。请使用不会和用户已加载配置里的名称冲突的组织专属名称。自定义名称不能以 : 开头，也不能使用保留名称 filesystem。

不要把托管自定义配置档案部署到运行 Codex 0.137.0 或更早版本的客户端。那些客户端能识别配置档案表，但不能识别选择它的托管默认值。

例如：

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# 有意省略 ":danger-full-access"，因此它会被拒绝。

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

只允许企业定义的配置档案

如果用户只能选择管理员定义的配置档案，请省略所有内建项：

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

这个自定义配置档案可以扩展 :workspace，即使用户不能直接选择内建的 :workspace 配置档案。

关闭另一个来源允许的配置档案

权限允许列表会按配置档案名称合并。由于 Codex 会先检查云端 requirements，再检查系统 requirements，云端 requirements 可以用 false 关闭系统文件允许的配置档案。

云端 requirements：

default_permissions = ":read-only"

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

系统 requirements：

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # 不会生效，因为云端 requirements 将它设为了 false。

请显式把 default_permissions 设为一个允许的配置档案。如果省略它，只有当 :workspace 和 :read-only 都被显式允许时，Codex 才会默认使用 :workspace。当 allowed_permission_profiles 不存在时，托管 requirements 不会限制用户可选择的配置档案名称。每个条目都必须指向内建配置档案，或指向已加载配置 / requirements 来源中定义的自定义配置档案。如果希望集中控制自定义配置档案的行为，请在托管 requirements 中定义它。

按主机覆盖沙箱强制规则

当同一份托管策略需要在不同主机上应用不同的沙箱要求时，可以使用 [[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 开关：它们可以在不启用该功能开关的情况下配置沙箱化网络，但如果当前激活的沙箱本身关闭了命令联网，它们不会授予命令网络访问。

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 限制，都与智能体审批与安全中描述的沙箱化网络行为一致。

固定功能开关

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

[features]
personality = true
unified_exec = false

# 需要时禁用特定 Codex 功能界面。
browser_use = false
browser_use_full_cdp_access = 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 可用性。
• browser_use_full_cdp_access = false 会阻止用户在 Browser Developer mode 中启用完整 CDP 访问。
• computer_use = false 会禁用 Computer Use（计算机操作）可用性及相关安装或设置流程。

如果省略这些键，策略会允许这些功能；实际可用性仍取决于普通客户端、平台和灰度发布条件。

限制锁定状态下的计算机操作

若要阻止 Computer Use（计算机操作） 在托管 Mac 锁定后继续操作，请添加这项 requirement：

[computer_use]
allow_locked_computer_use = false

这项 requirement 不会启用 Computer Use。它只会阻止 macOS 上的锁定状态使用。如果省略它，锁定状态使用不会被 requirements 约束，仍然取决于普通产品可用性和用户本地设置。

配置自动评审策略

使用 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] 一起固定下来。若要跳过用户、项目、会话和插件 hooks，同时仍允许托管 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"

注意事项：

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

通过 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 这类工具统一下发设置。一个轻量的部署流程通常如下：

1. 写好要下发的 TOML，再用 base64 编码，编码结果不要换行。
2. 把编码后的字符串放进 MDM 配置描述文件的 com.openai.codex 域，写到 config_toml_base64（托管默认值）或 requirements_toml_base64（强制规则）。
3. 下发配置描述文件后，让用户重启 Codex，并确认启动时显示的配置摘要已经反映管理员设置的值。
4. 如果需要撤销或调整策略，更新这份托管内容；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 表中；参见上方监控与遥测说明

推荐防护栏

• 对大多数用户，优先使用需要审批的 workspace-write；只有在受控容器环境中，才考虑开放完全访问。
• 除非你的安全评估已经允许访问 OTel 采集端或工作流所需域名，否则应保持 network_access = false。
• 可以用托管配置固定 OTel 的 exporter、environment 等设置，但除非策略明确允许保存提示词内容，否则应保持 log_user_prompt = false。
• 应定期检查本地 config.toml 与托管策略之间的差异，及时发现配置漂移；最终应始终以托管层覆盖本地文件和命令行参数。