下發託管配置

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。

ChatGPT Business 或 Enterprise 使用者登入 Codex 時，Codex 可以從服務端獲取 admin-enforced requirements。

這些 requirements 適用於 CLI、App 和 IDE Extension。

Codex 會盡力使用本地有效快取；快取缺失、過期、損壞或身份不匹配時，會嘗試從服務獲取並寫入 signed cache。

如果沒有有效快取，並且獲取失敗或超時，Codex 會繼續執行，但不會應用 cloud-managed requirements layer。企業需要把這個“best-effort”特性納入風險判斷。

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 server 能把 Codex 接到外部工具、資料和內部系統。企業環境不能只靠使用者自覺。

如果配置 MCP allowlist，只有 name 和 identity 都匹配 approved entry 時，Codex 才啟用該 server；否則停用。

這比“提示使用者別亂配”更可靠。

使用者嘗試開啟被禁止的 approval policy 或 sandbox mode 時，Codex 會回退到 compatible value。

未在 allowlist 的 MCP server 不會啟用。

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

不同使用者組拿到符合預期的 first matching requirements。

離線或 fetch 失敗時，你知道本地是否有有效 cache，以及無 cache 時的風險。