# Codex Features and Practical Usage 🏛️ When you roll Codex out company-wide, leaving "which MCPs, models, and permissions are allowed" to each person is risky. Managed configuration lets admins draw the boundaries and enforce them. 🏷️ Title: Centralized Managed Configuration & Governance 🔗 URL: 📘 Overview Codex enterprise managed configuration lets IT admins control agent behavior across the whole organization from a central place. Allowed MCP servers, models, and approval/sandbox permissions are distributed as policy so that users cannot quietly step outside the approved boundaries. ⚙️ How It Works Management has two tiers: ・`requirements.toml`: admin-enforced constraints that users cannot override. ・`managed_config.toml`: starting defaults that users can still change during a session. Precedence, highest to lowest: macOS MDM preferences → cloud-managed requirements (ChatGPT Business/Enterprise) → system files (`/etc/codex/` or `%ProgramData%\OpenAI\Codex\`) → the user's `config.toml` → CLI overrides. Managed layers override CLI flags and are reapplied every session. Lockable settings include approval policies, sandbox modes (e.g. blocking `full_access`), an allowlist of permission profiles, MCP server approval (by command or URL — omitted servers are disabled), feature flags (such as `browser_use`), enforced automatic review, network domain allow/deny lists, lifecycle hooks, and command rules. 🛠️ Practical Usage For example, a `requirements.toml` can pin `allowed_approval_policies` and `allowed_sandbox_modes`, set `deny_read` for `~/.ssh` and `.env`, add a prefix rule forbidding `rm`, and register a single approved MCP server. This blocks `full_access`, denies reads of `~/.ssh` and `.env`, forbids `rm`, and enables only the approved MCP server. 💡 Use Cases You can hand every employee only the MCP servers and models you have approved, and uniformly block reading secret files or running destructive commands — governance that stays consistent without redeploying clients. ⚠️ Caveats Once `allowed_permission_profiles` is defined, it becomes the exclusive list; later sources must explicitly re-enable a profile to use it. Cloud requirements are cached locally, so offline sessions may not reflect the latest policy. Don't push custom profiles to clients running Codex 0.137.0 or earlier. For group-based rules the first matching group wins, and unset fields are not inherited from later groups — use explicit allowlists to combine policies. #Codex# #Enterprise#