---
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="/zh-Hant/docs/codex/official/06-team-integration/54-enterprise-admin" />
  <Card title="治理和可觀測" description="配置下發後要能審計用量、策略命中和異常情況。" href="/zh-Hant/docs/codex/official/06-team-integration/56-governance-observability" />
  <Card title="審批安全" description="requirements 應該和 approval、sandbox、network 邊界共同設計。" href="/zh-Hant/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>
