enterprise/managed-configuration.md Codex Docs, 2026-04-25 00:42 UTC → 2026-05-18 22:01 UTC

76 76 

77Use `[[remote_sandbox_config]]` when one managed policy should apply different77Use `[[remote_sandbox_config]]` when one managed policy should apply different

78sandbox requirements on different hosts. For example, you can keep a stricter78sandbox requirements on different hosts. For example, you can keep a stricter

79default for laptops while allowing workspace writes on matching devboxes or CI79default for laptops while allowing workspace writes on matching dev boxes or CI

80runners. Host-specific entries currently override `allowed_sandbox_modes` only:80runners. Host-specific entries currently override `allowed_sandbox_modes` only:

81 81 

82```toml82```toml

94 94 

95The first matching `[[remote_sandbox_config]]` entry wins within the same95The first matching `[[remote_sandbox_config]]` entry wins within the same

96requirements source. If no entry matches, Codex keeps the top-level96requirements source. If no entry matches, Codex keeps the top-level

97`allowed_sandbox_modes`. Hostname matching is for policy selection only; don't97`allowed_sandbox_modes`. Host name matching is for policy selection only; don't

98treat it as authenticated device proof.98treat it as authenticated device proof.

99 99 

100You can also constrain web search mode:100You can also constrain web search mode:

106`allowed_web_search_modes = []` allows only `"disabled"`.106`allowed_web_search_modes = []` allows only `"disabled"`.

107For example, `allowed_web_search_modes = ["cached"]` prevents live web search even in `danger-full-access` sessions.107For example, `allowed_web_search_modes = ["cached"]` prevents live web search even in `danger-full-access` sessions.

108 108 

109You can also pin [feature flags](https://developers.openai.com/codex/config-basic/#feature-flags):109### Configure network access requirements

110 110 

111```111Use `[experimental_network]` in `requirements.toml` when administrators should

112[features]112define network access requirements centrally. These requirements are separate

113personality = true113from the user `features.network_proxy` toggle: they can configure sandboxed

114unified_exec = false114networking without that feature flag, but they do not grant command network

115access when the active sandbox keeps networking off.

116 

117```toml

118experimental_network.enabled = true

119experimental_network.dangerously_allow_all_unix_sockets = true

120experimental_network.allow_local_binding = true

121experimental_network.allowed_domains = [

122 "api.openai.com",

123 "*.example.com",

124]

125experimental_network.denied_domains = [

126 "blocked.example.com",

127 "*.exfil.example.com",

128]

115```129```

116 130 

117Use 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.131Use `experimental_network.managed_allowed_domains_only = true` only when you

132also define administrator-owned `allowed_domains` and want that allowlist to be

133exclusive. If it is `true` without managed allow rules, user-added domain allow

134rules do not remain effective.

118 135 

119### Disable Codex feature surfaces136The domain syntax, local/private destination rules, deny-over-allow behavior,

137and DNS rebinding limitations are the same as the sandboxed networking behavior

138described in [Agent approvals & security](https://developers.openai.com/codex/agent-approvals-security#network-isolation).

120 139 

121Admins can use `[feature_requirements]` to disable specific Codex feature140### Pin feature flags

122surfaces for users receiving a managed `requirements.toml`. You can also set

123the same keys in the existing `[features]` table.

124 141 

125```142You can also pin [feature flags](https://developers.openai.com/codex/config-basic/#feature-flags) for users

126[feature_requirements]143receiving a managed `requirements.toml`:

144 

145```toml

146[features]

147personality = true

148unified_exec = false

149 

150# Disable specific Codex feature surfaces when needed.

127browser_use = false151browser_use = false

128in_app_browser = false152in_app_browser = false

129computer_use = false153computer_use = false

130```154```

131 155 

156Use 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.

157 

158<a id="disable-codex-feature-surfaces"></a>

159 

132- `in_app_browser = false` disables the in-app browser pane.160- `in_app_browser = false` disables the in-app browser pane.

133- `browser_use = false` disables Browser Use and Browser Agent availability.161- `browser_use = false` disables Browser Use and Browser Agent availability.

134- `computer_use = false` disables Computer Use availability and related162- `computer_use = false` disables Computer Use availability and related

135 install or enablement flows.163 install or setup flows.

136 164 

137If omitted, these features are allowed by policy, subject to normal client,165If omitted, these features are allowed by policy, subject to normal client,

138platform, and rollout availability.166platform, and rollout availability.

190directory where your MDM or endpoint-management tooling installs the referenced218directory where your MDM or endpoint-management tooling installs the referenced

191scripts.219scripts.

192 220 

221To enforce managed hooks even for users who disabled hooks locally, pin

222`[features].hooks = true` alongside `[hooks]`.

223 

193```toml224```toml

194[features]225[features]

195codex_hooks = true226hooks = true

196 227 

197[hooks]228[hooks]

198managed_dir = "/enterprise/hooks"229managed_dir = "/enterprise/hooks"