Codex 受管配置分两类：requirements.toml（admin 强制约束，用户无法覆盖）和 managed_config.toml（下发默认值，用户可在 session 内修改）。本文说明两者的差异、各配置层的优先级、云端下发方式、macOS MDM 集成，以及具体的 requirements.toml 配置示例。

Codex 受管配置

企业管理员通过两种机制控制 Codex 本地行为：

• Requirements：admin 强制约束，用户无法覆盖
• Managed defaults：Codex 启动时应用的起始值，用户在 session 内可以修改，下次启动时重新应用

---

强制约束（requirements.toml）

Requirements 限制安全敏感设置（审批策略、沙箱模式、网络搜索模式，以及可选的 MCP Server 允许名单）。解析配置时，如果某个值与已强制的规则冲突，Codex 回退到兼容值并通知用户。

如果配置了 mcp_servers 允许名单，Codex 只有在名称和身份都匹配时才会启用 MCP Server，否则禁用。

Requirements 也可通过 [features] 表约束功能开关。未配置的键不受约束。

层级与优先级

Codex 按以下顺序应用 requirements（越靠前优先级越高）：

1. 云端受管 requirements（ChatGPT Business 或 Enterprise）
2. macOS 受管偏好设置（MDM）com.openai.codex:requirements_toml_base64
3. 系统 requirements.toml（Unix 系统下 /etc/codex/requirements.toml）

跨层合并逻辑：先配置的层设置某个字段（包括空列表）后，后续层不覆盖该字段，但低优先级层可以填充尚未设置的字段。

云端受管 requirements

用 ChatGPT Business/Enterprise 账号登录时，Codex 可以从服务端拉取 admin 强制 requirements。该机制适用于所有 Codex 界面（CLI、App、IDE Extension）。

配置方式：前往 Codex managed-config 页面 创建新的受管 requirements 文件。格式与 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 = "需要明确审批才能进入 shell" },
]

保存后立即对匹配用户生效。

分配给用户组：管理员可以为不同用户组配置不同 requirements，并设置默认回退策略。用户匹配多条组规则时第一条生效；Codex 不会从后续匹配组规则补充缺失字段。

本地应用机制：用户启动 Codex 时，Codex 先检查本地缓存（有效未过期则直接用），如缓存缺失或过期则从服务端拉取。拉取失败时 Codex 继续运行但不应用云端 requirements 层。

requirements.toml 示例

禁止 --ask-for-approval never 和 --sandbox danger-full-access（包括 --yolo）：

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

限制 Web 搜索模式（allowed_web_search_modes = [] 只允许 "disabled"）：

allowed_web_search_modes = ["cached"]

固定功能开关：

[features]
personality = true
unified_exec = false

在 requirements 中强制命令规则

管理员可以在 requirements.toml 的 [rules] 表中强制执行命令规则。这些规则与普通 .rules 文件合并，最严格的决策获胜。

与 .rules 不同，requirements 规则必须指定 decision，且只能是 "prompt" 或 "forbidden"（不能是 "allow"）：

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "请用 git clean -fd 代替。" },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "修改历史前需要人工确认。" },
]

限制 MCP Server：

# stdio 服务：匹配 command
[mcp_servers.docs]
identity = { command = "codex-mcp" }

# HTTP 服务：匹配 url
[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

mcp_servers 存在但为空时，Codex 禁用所有 MCP Server。

---

受管默认值（managed_config.toml）

受管默认值合并在用户本地 config.toml 之上，优先级高于所有 CLI --config 覆盖，设定 Codex 启动时的初始值。用户在 session 内可以修改，但下次启动时 Codex 重新应用受管默认值。

优先级和层级

Codex 按以下顺序组合最终配置（越靠前优先级越高）：

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

CLI 的 --config key=value 覆盖应用于基础配置，但受管层会覆盖它。即使提供本地 flag，每次启动都从受管默认值开始。

文件位置

• Linux/macOS（Unix）：/etc/codex/managed_config.toml
• Windows/非 Unix：~/.codex/managed_config.toml

文件不存在时，Codex 跳过受管层。

---

macOS MDM 集成

在 macOS 上，管理员可以通过设备配置文件推送 base64 编码的 TOML payload：

• Preference domain：com.openai.codex
• config_toml_base64：受管默认值
• requirements_toml_base64：requirements

Codex 将这些"受管偏好设置"payload 解析为 TOML。对于受管默认值（config_toml_base64），受管偏好设置拥有最高优先级。

MDM 部署步骤

支持 Jamf Pro、Fleet、Kandji 等标准 macOS MDM 工具：

1. 构建受管 payload TOML，用 base64 编码（不换行）
2. 在 MDM Profile 中，在 com.openai.codex domain 下的 config_toml_base64（受管默认值）或 requirements_toml_base64（requirements）键中填入字符串
3. 推送 Profile，让用户重启 Codex，确认启动配置摘要反映了受管值
4. 修改策略时更新受管 payload；CLI 在下次启动时读取刷新后的偏好设置

不要在 payload 中嵌入密钥或高频变化的动态值。将受管 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"   # 指向你的 OTel collector
log_user_prompt = false  # 保持 prompt 内容匿名

推荐防护策略

• 对大多数用户使用 workspace-write + 审批；仅在受控容器中保留完全访问权限
• 保持 network_access = false，除非安全评审允许特定域名或 collector
• 通过受管配置固定 OTel 设置（exporter、environment），但保持 log_user_prompt = false，除非策略明确允许存储 prompt 内容
• 定期审计本地 config.toml 和受管策略之间的差异，检测配置漂移；受管层应优先于本地 flag 和文件

---

常见问题

Q: requirements.toml 和 managed_config.toml 的本质区别是什么？

A: requirements.toml 是强制约束——一旦管理员设置，用户无法覆盖，Codex 检测到冲突时会强制回退到兼容值。managed_config.toml 是受管默认值——用户在当前 session 内可以修改，但下次启动 Codex 时又会回到受管默认值。

Q: 云端下发的 requirements 和 /etc/codex/requirements.toml 哪个优先级更高？

A: 云端受管 requirements 优先级最高，其次是 macOS MDM，再次是 /etc/codex/requirements.toml。但合并逻辑是"先设置的字段不被后续层覆盖"，所以如果某个字段只在 /etc/codex/requirements.toml 里有，云端没有设置，仍然会生效。

Q: 用户通过 API Key 登录时，云端受管 requirements 还会生效吗？

A: 不会。云端受管 requirements 只在用户用 ChatGPT Business/Enterprise 账号登录时获取。API Key 登录时只有系统级 /etc/codex/requirements.toml 和 MDM 生效。