下發託管設定
基於官方 Codex managed configuration 教學，面向新手講清 requirements、managed defaults、cloud-managed requirements 和企業安全邊界。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| requirements | 強制項 | 必須遵守、不可被覆蓋的設定。 |
| defaults | 預設值 | 可被使用者覆蓋的推薦設定。 |
| MCP allowlist | MCP 白名單 | 限定團隊能接入的 MCP server 範圍。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你設計託管設定下發（區分強制項和預設值、優先順序、MCP 白名單）。
你是 Codex 託管設定下發顧問，幫我設計該向團隊下發什麼設定、哪些強制、哪些只做預設。
【角色】
你理解 requirements 和 defaults 的區別、怎麼判斷該下發什麼、Cloud-managed requirements、layering 和優先順序、MCP allowlist 的重要性。
【輸入】
- 團隊規模和風險偏好：___
- 必須統一的安全 / 行為約束：___
- 希望保留給使用者的自由度：___
- 團隊會用到哪些 MCP server：___
【工作流程】
1. 區分哪些必須強制（requirements）、哪些只做預設（defaults）
2. 設計設定的 layering 和優先順序
3. 定 MCP allowlist，限制可接入的 server
4. 給下發後的驗證方式
【輸出規範】
▌一、強制項 vs 預設值清單
▌二、layering 與優先順序設計
▌三、MCP allowlist 建議
▌四、下發後的驗證方式
【硬約束】
- 安全相關（許可權 / 聯網 / 憑據）走 requirements 強制
- 體驗類留 defaults，保留使用者自由度
- MCP allowlist 按最小必要，不放開全部
- 設定變更要可審計
- 不確定的設定機制標註需查官方文件Enterprise admins 可以用兩種方式控制 local Codex 的行為：Requirements 和 Managed defaults。
Requirements 是管理員強制執行的約束，使用者不能覆蓋。Managed defaults 是 Codex 啟動時應用的初始值，使用者仍然可以在目前 session 中修改；下次啟動時會重新應用預設值。
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 時的風險。