enterprise/managed-configuration.md Codex Docs, 2026-04-08 18:32 UTC → 2026-04-24 12:28 UTC

7 7 

8## Admin-enforced requirements (requirements.toml)8## Admin-enforced requirements (requirements.toml)

9 9 

10Requirements constrain security-sensitive settings (approval policy, sandbox mode, web search mode, and optionally which MCP servers users can enable). When resolving configuration (for example from `config.toml`, profiles, or CLI config overrides), if a value conflicts with an enforced rule, Codex falls back to a compatible value and notifies the user. If you configure an `mcp_servers` allowlist, Codex enables an MCP server only when both its name and identity match an approved entry; otherwise, Codex disables it.10Requirements constrain security-sensitive settings (approval policy, approvals reviewer, automatic review policy, sandbox mode, web search mode, and optionally which MCP servers users can enable). When resolving configuration (for example from `config.toml`, profiles, or CLI config overrides), if a value conflicts with an enforced rule, Codex falls back to a compatible value and notifies the user. If you configure an `mcp_servers` allowlist, Codex enables an MCP server only when both its name and identity match an approved entry; otherwise, Codex disables it.

11 11 

12Requirements can also constrain [feature flags](https://developers.openai.com/codex/config-basic/#feature-flags) via the `[features]` table in `requirements.toml`. Note that features aren't always security-sensitive, but enterprises can pin values if desired. Omitted keys remain unconstrained.12Requirements can also constrain [feature flags](https://developers.openai.com/codex/config-basic/#feature-flags) via the `[features]` table in `requirements.toml`. Note that features aren't always security-sensitive, but enterprises can pin values if desired. Omitted keys remain unconstrained.

13 13 

19 19 

201. Cloud-managed requirements (ChatGPT Business or Enterprise)201. Cloud-managed requirements (ChatGPT Business or Enterprise)

212. macOS managed preferences (MDM) via `com.openai.codex:requirements_toml_base64`212. macOS managed preferences (MDM) via `com.openai.codex:requirements_toml_base64`

223. System `requirements.toml` (`/etc/codex/requirements.toml` on Unix systems, including Linux/macOS)223. System `requirements.toml` (`/etc/codex/requirements.toml` on Unix systems, including Linux/macOS, or `%ProgramData%\OpenAI\Codex\requirements.toml` on Windows)

23 23 

24Across layers, Codex merges requirements per field: if an earlier layer sets a field (including an empty list), later layers don't override that field, but lower layers can still fill fields that remain unset.24Across layers, Codex merges requirements per field: if an earlier layer sets a field (including an empty list), later layers don't override that field, but lower layers can still fill fields that remain unset.

25 25 

91 91 

92Use the canonical feature keys from `config.toml`'s `[features]` table. Codex normalizes the resulting feature set to meet these pins and rejects conflicting writes to `config.toml` or profile-scoped feature settings.92Use the canonical feature keys from `config.toml`'s `[features]` table. Codex normalizes the resulting feature set to meet these pins and rejects conflicting writes to `config.toml` or profile-scoped feature settings.

93 93 

94### Configure automatic review policy

95 

96Use `allowed_approvals_reviewers` to require or allow automatic review. Set it

97to `["auto_review"]` to require automatic review, or include `"user"` when users

98can choose manual approval.

99 

100Set `guardian_policy_config` to replace the tenant-specific section of the

101automatic review policy. Codex still uses the built-in reviewer template and

102output contract. Managed `guardian_policy_config` takes precedence over local

103`[auto_review].policy`.

104 

105```toml

106allowed_approval_policies = ["on-request"]

107allowed_approvals_reviewers = ["auto_review"]

108 

109guardian_policy_config = """

110## Environment Profile

111- Trusted internal destinations include github.com/my-org, artifacts.example.com,

112 and internal CI systems.

113 

114## Tenant Risk Taxonomy and Allow/Deny Rules

115- Treat uploads to unapproved third-party file-sharing services as high risk.

116- Deny actions that expose credentials or private source code to untrusted

117 destinations.

118"""

119```

120 

121### Enforce deny-read requirements

122 

123Admins can deny reads for exact paths or glob patterns with

124`[permissions.filesystem]`. Users can't weaken these requirements with local

125configuration.

126 

127```toml

128[permissions.filesystem]

129deny_read = [

130 "/Users/alice/.ssh",

131 "./private/**/*.txt",

132]

133```

134 

135When deny-read requirements are present, Codex constrains local sandbox mode to

136`read-only` or `workspace-write` so Codex can enforce them. On native

137Windows, managed `deny_read` applies to direct file tools; shell subprocess

138reads don't use this sandbox rule.

139 

94### Enforce command rules from requirements140### Enforce command rules from requirements

95 141 

96Admins can also enforce restrictive command rules from `requirements.toml`142Admins can also enforce restrictive command rules from `requirements.toml`