---
title: "下发托管配置"
description: "基于官方 Codex managed configuration 教程，面向新手讲清 requirements、managed defaults、cloud-managed requirements 和企业安全边界。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

Enterprise admins 可以用两种方式控制 local Codex 的行为：Requirements 和 Managed defaults。

Requirements 是管理员强制执行的约束，用户不能覆盖。Managed defaults 是 Codex 启动时应用的初始值，用户仍然可以在当前 session 中修改；下次启动时会重新应用默认值。

> [!WARNING]
> Managed defaults 不是安全边界。涉及审批、沙箱、联网、MCP allowlist、feature flags 和企业合规时，用 requirements，并验证用户无法覆盖。

## 先理解：requirements 和 defaults 的区别

Requirements 解决安全底线问题。比如禁止 `danger-full-access`、限制 approval policy、限制 web search、限制 MCP servers、固定 feature flags、强制 managed hooks。

Managed defaults 解决默认体验问题。比如默认模型、默认 sandbox、默认设置。它影响起点，但不是不可变边界。

新手记住：涉及安全、合规、数据边界的，用 requirements；涉及偏好和默认值的，用 defaults。

## 怎么判断该下发什么

如果目标是防止用户绕过审批、开启危险 sandbox、使用未批准 MCP、打开 live web search，就下发 requirements。

如果目标是让团队默认用某个模型、某个 effort、某组常用配置，就下发 managed defaults。

如果目标是团队 CI 或 devbox 放宽写权限，而普通 laptop 保持严格，就考虑 host-specific sandbox requirements。

如果目标是禁用某些功能入口，例如 in-app browser、Browser Use 或 Computer Use，就用 feature flags。

## Cloud-managed requirements 怎么理解

ChatGPT Business 或 Enterprise 用户登录 Codex 时，Codex 可以从服务端获取 admin-enforced requirements。

这些 requirements 适用于 CLI、App 和 IDE Extension。

Codex 会尽力使用本地有效缓存；缓存缺失、过期、损坏或身份不匹配时，会尝试从服务获取并写入 signed cache。

如果没有有效缓存，并且获取失败或超时，Codex 会继续运行，但不会应用 cloud-managed requirements layer。企业需要把这个“best-effort”特性纳入风险判断。

## layering 和优先级怎么理解

Requirements 可能来自 cloud-managed、macOS MDM managed preferences、system `requirements.toml` 等层。

同一个字段里，更高优先级的 layer 设置后，低优先级不能覆盖；低优先级只能补高优先级没有设置的字段。

group-specific cloud rules 也要小心：如果用户匹配多个 group，Codex 使用第一个 matching rule，不会从后面的 matching group rules 补 unset fields。

## MCP allowlist 为什么重要

MCP server 能把 Codex 接到外部工具、数据和内部系统。企业环境不能只靠用户自觉。

如果配置 MCP allowlist，只有 name 和 identity 都匹配 approved entry 时，Codex 才启用该 server；否则禁用。

这比“提示用户别乱配”更可靠。

## 新手常见坑

- 把 managed defaults 当安全边界：用户当前 session 仍可能修改。
- 只限制 sandbox，不限制 web search、MCP、feature flags。
- group rule 顺序没设计好，导致后面的策略永远不生效。
- 以 hostname matching 当设备认证：官方说明它只是选择 policy，不是 authenticated proof。
- cloud requirements fetch 失败时没有 fallback 风险预案。
- requirements 写太宽，形同虚设。

## 怎么验收

用户尝试开启被禁止的 approval policy 或 sandbox mode 时，Codex 会回退到 compatible value。

未在 allowlist 的 MCP server 不会启用。

被 pin 的 feature flag 不能被本地 config 或 profile 覆盖。

不同用户组拿到符合预期的 first matching requirements。

离线或 fetch 失败时，你知道本地是否有有效 cache，以及无 cache 时的风险。

## 官方资料

- [Managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration)
- [requirements.toml reference](https://developers.openai.com/codex/config-reference#requirementstoml)
- [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security)
- [MCP configuration](https://developers.openai.com/codex/mcp)

## 接下来去哪

<Cards>
  <Card title="企业管理员初始化" description="托管配置前先建立团队、身份、权限和治理入口。" href="/docs/codex/official/06-team-integration/54-enterprise-admin" />
  <Card title="治理和可观测" description="配置下发后要能审计用量、策略命中和异常情况。" href="/docs/codex/official/06-team-integration/56-governance-observability" />
  <Card title="审批安全" description="requirements 应该和 approval、sandbox、network 边界共同设计。" href="/docs/codex/official/02-config-security/07-approval-security" />
  <Card title="官方 Managed configuration" description="字段、优先级和云端 requirements 行为以官方页面为准。" href="https://developers.openai.com/codex/enterprise/managed-configuration" />
</Cards>
