## What changed
Allow shared network constraints in `[permissions.network]` in `requirements.toml`, alongside `[permissions.filesystem]`. Apply them throughout configuration loading, network approvals, Windows sandbox policy validation, and `configRequirements/read`, and show their source in `/debug-config`.
Retain `[network_proxy]` and `[experimental_network]`, but reject mixing either with `[permissions.network]`, even across requirements layers. Preserve independent network and filesystem precedence and source attribution, and report unknown nested network fields.
Reserve `network` as a managed requirements table name and reject empty or profile-shaped tables with migration guidance. Profiles named `network` remain valid in `config.toml`. Document that policy publishers must keep using `[experimental_network]` until all readers support the chosen replacement.
## Testing
Add coverage for layered constraints and source attribution, conflicting spellings, profile-name migration errors, unknown-field diagnostics, and cloud validation. Extend API, project discovery, network approval, and Windows policy tests to cover `[permissions.network]`, and verify managed proxy settings remain independent of disabled feature configuration.
GitOrigin-RevId: 994dfca9abf5a7aea914276c0ded8b40d7ed0372
## Why
Managed OpenTelemetry requirements could not specify span attributes or tracestate metadata.
## What changed
- Accept `otel.span_attributes` and `otel.tracestate` in requirements, merge them by attribute or member field, and expose them through app-server configuration and requirements reads.
- Protect required entries and their ancestors from configuration writes while preserving unmanaged sibling values and their origins. For example, requiring `otel.tracestate.vendor.tenant` leaves `vendor.region` writable. Empty metadata maps impose no requirements.
- Select Rustls when configuring an OTLP HTTP client certificate and private key so PEM client identities are accepted.
## Testing
Add coverage for metadata precedence, effective configuration, field-level write protection, and preservation of unmanaged values. Add blocking and asynchronous HTTP client construction tests using generated PEM certificates and keys.
GitOrigin-RevId: ada6000cc5e575b9a33451ec4aa58b6686dc20f7
## What changed
- Allow `requirements.toml` to manage OpenTelemetry logging flags, tool-result byte limits, environment, and log, trace, and metrics exporters.
- Apply higher-priority managed values over user configuration, replacing exporters atomically and warning when configured values conflict. Preserve unmanaged settings, including `span_attributes` and `tracestate`.
- Expose managed `otel` settings through `configRequirements/read`, apply them in `config/read` without ordinary field origins, and reject configuration writes that overlap managed fields.
- Distinguish omitted tool-result limits from explicit values while preserving the runtime default.
## Testing
Add coverage for requirement precedence, relative TLS paths, override warnings, managed write protection, effective configuration reads, and exporter serialization through the app-server API.
GitOrigin-RevId: 6a3343563bd3acb53a366ea6723684e3d0a4a01d
## What changed
Accept `[network_proxy]` in `requirements.toml`, retaining `[experimental_network]` as a compatibility alias. Reject both names in a single layer and normalize them before merging across layers so precedence and source tracking are preserved.
Honor the new spelling during credential broker project discovery, display `network_proxy` in debug configuration, and update diagnostics and documentation. Document the distinction between managed requirements, proxy feature configuration, and permission profiles. Policy publishers must keep using `[experimental_network]` until all clients and policy validation layers support the new spelling.
## Testing
Add coverage for alias equivalence, duplicate rejection, cross-layer precedence and sources, and broker project discovery. Exercise both spellings in proxy configuration, network approval routing, app-server requirements responses, and Windows machine policy validation.
GitOrigin-RevId: 5c5bb82bd4b6b1431aa97f27248775820eae6302
## Why
Existing databases retain their journal mode, so selecting `DELETE` for new NFS databases leaves existing WAL databases unchanged.
## What changed
- Add the managed `unsafe_enforce_sqlite_journal_mode` requirement to migrate existing NFS databases before opening writable pools and require `DELETE` on each connection.
- Share migration code between startup and `codex migrate-nfs-db`, preserving WAL backups and resuming interrupted replacements, including lazily opened databases.
- Hold the migration lock through pool initialization and keep migration failures out of automatic corruption recovery.
- Preserve local logs behavior and skip legacy NFS logs cleanup when enforcement is enabled.
## Testing
Add coverage for requirement precedence, database settings, data and backup preservation across restarts, interrupted replacement recovery, refusal of active WAL databases, migration lock waiting, and local logs remaining in WAL mode.
GitOrigin-RevId: da41ec1b58b1ee8092591cdf8b358280928ff9d4
## Why
Local administrators need to require managed configuration from a specific customer-hosted server before a session can start.
## What changed
- Add a local managed `config_server` requirement with an HTTPS base URL and optional OAuth settings. Validate endpoints and derive the bundle route as `codex/config/bundle` beneath the base URL.
- Replace the entire `config_server` block when a higher-priority requirements layer supplies one, keeping the endpoint and OAuth settings together. Reject this setting in fetched policy.
- Track the applied server through configuration snapshots, role overrides, and refreshes. Reject session startup and managed refreshes when the applied server does not match the requirement; user refreshes retain the session's managed configuration.
## Testing
Add coverage for missing, mismatched, and matching server configuration at session startup, whole-block replacement, rejection of server settings in fetched policy, and preservation across role overrides and refreshes.
GitOrigin-RevId: 51e8a1738dabdb117ae858120f6fb09ae2ff1261
## What changed
- Add `auto_review.extra_policy` and the managed `guardian_extra_policy` requirement to supply policy text alongside the resolved tenant policy. Nonblank managed values take precedence; blank values are ignored.
- Render the additional text through `{{ extra_policy }}` in Guardian reviewer templates and append it to the tenant policy for Guardian v2 classification before truncation.
- Preserve placeholder-like text inside supplied policies literally.
## Testing
Add coverage for configuration precedence, blank values, template substitution, and classifier prompts, plus a scenario verifying that managed tenant and extra policies reach the Guardian reviewer together.
GitOrigin-RevId: 180d8d716c63fe96a92ec5bfbd22db4ddccd4f1f
## What changed
- Support `model_provider` and `model_providers` in managed requirements. Required selection overrides local and session configuration; each required provider definition replaces the corresponding local entry, including its authentication and headers.
- Merge provider requirement fragments before validation, preserving source-relative `auth.cwd` paths. Reject invalid cloud provider definitions before replacing the cached bundle, including unsupported Bedrock overrides.
- Expose `modelProvider` and `modelProviders` through the configuration requirements API and generated schemas. Reject writes to managed provider settings and omit their local origins, including for provider IDs containing dots.
## Testing
Add tests for requirement precedence, authentication fragment merging, path resolution, cloud cache preservation, and read-only configuration RPCs. Integration tests verify that model discovery and inference use the required gateway and ChatGPT authentication without leaking local headers, and that provider requirements survive configuration rebuilds.
GitOrigin-RevId: d1448604d4ef5662ebb5df7b693712d3b8ad6d54
## What changed
- Add `application.network` managed requirements with exact-domain allow/deny
rules, default-enabled behavior, domain normalization, and normal managed TOML
precedence.
- Return the policy separately from agent network requirements through the
experimental `configRequirements/read` API. The endpoint reports the policy
but does not enforce it.
- Export the new protocol types and schemas, and document the TOML format.
## Testing
- Cover parsing, validation, normalization, layered precedence, and cloud
requirement composition.
- Verify app-server responses, defaults, separation from agent policy, and
rejection of invalid domains.
GitOrigin-RevId: 563eeed296d9748430b819797204a44a8db92f3b
## What changed
- Add a top-level `allow_browser_and_computer_use` requirement.
- Support browser requirements for history access, automatic review, persistent approvals, and default or per-origin access policies.
- Support computer-use requirements for persistent approvals, default app access, macOS bundle IDs, Windows AUMIDs, and Windows executables.
- Preserve these settings and their sources when composing layered requirements.
## Testing
- Cover deserialization, empty-value detection, source propagation, and layered TOML merging for the new requirements.
GitOrigin-RevId: d14a10b64465f1c54e9bcc3795dc93031e6b029b
## What changed
- Add `additional_developer_instructions` to managed requirements and expose it through `configRequirements/read` as `additionalDeveloperInstructions`, independently of ordinary developer instructions.
- Include the managed instructions in model context, emit explicit replacement or removal messages when requirements change, and preserve the current value across compaction, resume, and agent forks without duplication.
- Reject managed instructions whose rendered context exceeds 10,000 estimated tokens.
## Testing
- Cover requirements layering and API serialization, context updates and removal, size validation, repeated model requests, compaction and resume, rollout migration, and agent forks.
GitOrigin-RevId: bc0b70fb7988944c2f68176dff55f5ed61eb46c8
## What changed
- Add `in_app_browser.allow_external_browser_settings_import` to managed requirements, preserving explicit Boolean values through layered composition while leaving an omitted value unset.
- Return the policy as `inAppBrowser.allowExternalBrowserSettingsImport` from `configRequirements/read` and include it in the generated protocol schemas.
- Keep the import policy independent from the in-app browser feature flag and agent Browser Use requirements.
## Testing
- Cover parsing, managed-layer precedence, invalid values, user and session override resistance, and app-server response serialization.
GitOrigin-RevId: efa2621d2b1cf503f1bee2505d9914cb4fb7221d
## What changed
- Add `cli_auth_credentials_store` and `chatgpt_base_url` as exact managed requirements loaded from local requirements configuration.
- Apply these requirements to runtime and bootstrap authentication configuration, overriding user-configured values.
- Expose the managed values through `configRequirements/read` and reject attempts to change them through config write APIs.
- Ignore these local-only authentication requirements in cloud-managed requirement layers.
## Testing
- Cover requirement loading and composition, runtime and bootstrap overrides, app-server responses, and read-only config writes.
GitOrigin-RevId: 8ea9c096386072036ca5441f3d48af8707988a65
## What changed
- Add a scoped `AbsolutePathBufGuard::with_home_directory` override so `~`
paths can resolve against an explicitly supplied home directory while
preserving the existing base-directory behavior. Nested overrides restore
the previous home directory.
- Expose `compose_requirements_for_hostname` so callers can evaluate
`remote_sandbox_config` for a supplied execution-host hostname.
- Cover cloud bundle conversion with execution-host path expansion and
hostname-specific sandbox requirements.
GitOrigin-RevId: 6fd486992b45ff92e22bb4073b888252b544f285
## What changed
- Filter saved `allow` prefix rules from the execution policy for cyber-specialized models and models listed in `auto_review.ignore_rules`, while preserving prompt, forbidden, network, and host-executable policy entries.
- Apply the filtered policy consistently to permission instructions, shell commands, unified exec, and the zsh-fork backend.
- Limit cyber-model command approvals to one-time decisions without proposing reusable policy amendments. General models continue to honor saved prefixes, including after switching models within a thread.
## Testing
- Add policy-level coverage for filtering allow-prefix rules while retaining restrictive and network rules.
- Add end-to-end coverage across shell and unified exec paths, zsh-fork execution, user and automatic review, and model switching.
GitOrigin-RevId: f3bd3872424291b12354ec415f33986ec369a368
## What changed
- Add the managed `auto_review.required_on_models` requirement, unioning model slugs across requirement layers and exposing the result through `configRequirements/read`.
- Force listed models to use `on-request` approvals with the `auto_review` reviewer. Downgrade Full Access to workspace-write when starting a protected session, and reject incompatible runtime overrides or use when automatic review is disabled.
- Preserve these protections across thread starts, resumes, forks, model changes, turn overrides, MCP approvals, and TUI session attachment.
## Testing
- Add coverage for layered model requirements and exact provider-alias matching.
- Add app-server tests for protected thread lifecycle operations, unsafe setting overrides, legacy thread upgrades, disabled automatic review, and requirements API output.
GitOrigin-RevId: c4b1d52c3b5b75e86880725412b8f0812e0dfcd9
## Why
Authentication restrictions must apply before stored or environment-provided credentials can be used, including during bootstrap before cloud requirements are fetched.
## What changed
- Add local `requirements.toml` allowlists for login methods and ChatGPT workspaces. Ignore these fields in cloud-provided requirements.
- Combine managed workspace allowlists with existing workspace restrictions by intersection, and fail closed when the resulting policy permits no usable login method.
- Centralize policy checks in the authentication manager so CLI, TUI, app-server, external-auth, and credential-loading paths consistently reject disallowed authentication before token hydration or network requests.
## Testing
- Cover policy composition, workspace intersection, invalid stored and external credentials, bootstrap enforcement, and login endpoint restrictions.
GitOrigin-RevId: efef22b248f3c3333e9aa55423e539efa2d2dd48
## What changed
- Parse the `browser_use.disable_auto_review` setting from layered
`requirements.toml` configuration.
- Return the setting as `browserUse.disableAutoReview` from
`configRequirements/read` and publish it in the generated JSON and TypeScript
schemas.
## Testing
- Add an app-server RPC test covering the Browser Use requirement.
GitOrigin-RevId: 5749d5bc17bcc5b582bf7ed59b8e5b72d6c8f7fc
## What changed
- Apply managed values for `sqlite_home`, `log_dir`, `model_catalog_json`,
`check_for_update_on_startup`, `allow_login_shell`, the report-submission
opt-in, and `windows.sandbox_private_desktop` to the runtime configuration,
with source-aware warnings when they override configured values.
- Expose these values through `configRequirements/read`, return them from
`config/read`, include them in session config locks, and show their sources in
the TUI config debug view.
- Reject app-server writes that overlap an exact managed requirement with
`configRequirementReadonly` while leaving unrelated sibling keys writable.
## Testing
- Cover runtime overrides, requirement API mapping, config reads and writes,
session lock serialization, cross-platform path URIs, and debug output.
GitOrigin-RevId: d4e23b6fd7775c1a6dfe2eab313cdcee50b07081
## Why
Admins need persistent defaults for the model, reasoning effort, and
service tier shown when the Desktop App creates a new thread. These are
initialization defaults rather than runtime constraints: the App should
use them to initialize its draft while still allowing a user to make an
explicit selection.
The app-server therefore needs to expose the managed values before
thread creation without changing `thread/start` behavior for other
clients.
## What changed
- Parse `model`, `model_reasoning_effort`, and `service_tier` from
`[models.new_thread]` in `requirements.toml`.
- Compose the `models` requirements through the existing
requirements-layer precedence rules.
- Expose the resolved values through `configRequirements/read` as
`requirements.models.newThread`.
- Add the corresponding app-server protocol types and regenerate the
JSON and TypeScript schema fixtures.
- Document the new `configRequirements/read` fields in the app-server
README.
## Scope
This PR is data plumbing only. It does not apply these values during
`thread/start` and does not change thread creation for existing
app-server clients, resumed or forked sessions, internal or subagent
sessions, `codex exec`, or the TUI. A companion Desktop App change owns
draft initialization, sends the effective settings for ordinary and
prewarmed starts, and preserves explicit user changes.
## Validation
- Requirements deserialization coverage for `[models.new_thread]`
- Requirements-layer precedence coverage
- App-server API mapping coverage
- `configRequirements/read` integration coverage
- Regenerated app-server JSON and TypeScript schema fixtures
## Why
Managed deployments need a mergeable way to declare which marketplace
sources Codex may use. An enterprise-keyed TOML table avoids array merge
ambiguity and lets every requirements layer use the existing config
precedence rules without a marketplace-specific merger.
## Requirements shape
```toml
[marketplaces]
restrict_to_allowed_sources = true
[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"
[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = "^git\\.example\\.com$"
[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"
```
`restrict_to_allowed_sources` follows normal scalar precedence.
`allowed_sources` follows normal recursive TOML table merge behavior:
distinct keys accumulate and fields under the same key use normal layer
precedence. The final `source` value later selects which fields the
marketplace admission policy interprets.
The raw rule fields remain optional while requirements layers are
composed, so a higher-priority layer can override only `ref`, `url`, or
another individual field. Source-specific validation and normalization
intentionally belong to the marketplace admission layer, not
requirements merging.
This initial shape includes `git`, `host_pattern`, and `local` sources.
It does not add npm or path-pattern rules.
## What changed
- Add the marketplace requirements TOML shape to
`ConfigRequirementsToml`, `ConfigRequirementsWithSources`, and
`ConfigRequirements`.
- Carry marketplace requirements through the existing regular
requirements merge path.
- Keep allowed-source entries as raw partial tables for downstream
policy interpretation.
- Cover partial same-key overlays, source changes, unknown fields, and
unmodified local paths.
This PR defines and composes the requirements only. Source admission is
implemented by the next PR in the stack.
## Stack
This is PR 1 of 3. #29753 adds source admission on top of this PR; draft
#29691 will add runtime enforcement after it is rebased later.
## Test plan
- `just test -p codex-config marketplace_`
## Why
[#18763](https://github.com/openai/codex/pull/18763) added canonical
hostname resolution for `remote_sandbox_config`. Requirements
composition currently performs that synchronous DNS lookup on every
fresh process, even when none of the loaded requirements layers contains
`[[remote_sandbox_config]]`. On hosts with slow local DNS resolution,
this can add several seconds to Codex startup.
## What
- defer hostname resolution until a parsed requirements layer actually
contains `remote_sandbox_config`
- cache the resolver result once per requirements composition,
preserving the existing single-lookup behavior across multiple layers
- keep the existing FQDN resolution and per-layer requirements
precedence unchanged
- cover both the ordinary no-lookup path and the multi-layer
single-lookup path
## How to Test
On a host where local canonical-name resolution is slow:
1. Start Codex without `[[remote_sandbox_config]]` in any managed
requirements layer and confirm startup no longer waits for hostname
resolution.
2. Add a matching `[[remote_sandbox_config]]` entry and confirm its
`allowed_sandbox_modes` still overrides the layer's top-level value.
3. Add remote sandbox entries to multiple requirements layers and
confirm precedence remains unchanged while the hostname is resolved only
once.
Targeted tests:
- `just test -p codex-config hostname_resolver`
- `just test -p codex-config` (181 passed)
## Why
Managed deployments need a reliable deny gate for remote control.
Persisted enablement and explicit startup requests currently remain able
to start the transport, while the removed `features.remote_control` key
is intentionally only a compatibility no-op.
This adds a dedicated requirement that administrators can use to force
remote control off without deleting the user's persisted preference.
Removing the requirement and restarting restores the prior choice.
## What Changed
- Added top-level `allow_remote_control` requirements parsing, sourced
layer precedence, debug output, and `configRequirements/read` exposure
as `allowRemoteControl`.
- Added a typed transport policy captured from the startup requirements
snapshot. Managed disable forces the initial state to disabled and
prevents enrollment, refresh, connection, and persisted-preference
mutation.
- Rejected every `remoteControl/*` RPC before parameter deserialization
with JSON-RPC `-32600` and `remote control is disabled by managed
requirements`.
- Preserved the existing disabled status notification and the previous
behavior when the requirement is `true` or omitted.
- Regenerated app-server protocol schemas and documented the new
requirement.
## Verification
- Confirmed all remote-control RPCs, including a malformed request,
return the managed-policy error while the initial status notification
remains `disabled`.
- Confirmed explicit ephemeral startup and persisted enablement make no
backend connection and leave the SQLite preference unchanged.
- Confirmed `allow_remote_control = true` does not enable or block
remote control and `configRequirements/read` returns
`allowRemoteControl: false` for the deny policy.
Related issue: N/A (managed-policy hardening).
## Why
Permission profile allowlists are an enterprise security boundary, but
they also need to compose across the managed requirements layers added
in #24620.
A map representation lets each requirements layer add, allow, or revoke
individual profiles without replacing an entire array.
## Managed Contract
Administrators configure the mergeable allow map with
`allowed_permission_profiles`. A recommended enterprise configuration
explicitly lists every built-in and custom profile users should be able
to select:
```toml
default_permissions = "review_only"
[allowed_permission_profiles]
":read-only" = true
":workspace" = true
review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.
[permissions.review_only]
extends = ":read-only"
```
- Profiles whose effective merged value is `true` are allowed.
- Missing profiles and profiles set to `false` are denied.
- This is a closed allowlist: built-in profiles and profiles introduced
in future versions are denied unless explicitly allowed.
- Explicitly list each built-in profile the enterprise wants to make
available. Omit built-ins such as `:danger-full-access` when they should
remain unavailable.
- Set `default_permissions` explicitly to the allowed profile users
should receive when they have no local selection.
- Higher-precedence layers override only the profile keys they define.
- `false` is only needed when a higher-precedence layer must revoke a
`true` inherited from a lower layer.
- Explicit keys must refer to known built-in or managed profiles.
A custom or narrowed allowlist requires an allowed
`default_permissions`. For compatibility, if both `:workspace` and
`:read-only` are explicitly allowed, an omitted default resolves to
`:workspace`; customer configurations should still set the intended
default explicitly.
When `allowed_permission_profiles` is absent, existing implicit
permission and legacy `sandbox_mode` behavior is unchanged.
## What Changed
- Add `allowed_permission_profiles` as a `BTreeMap<String, bool>` that
merges per profile across requirements layers.
- Enforce managed defaults, strict denial of omitted profiles, and the
explicitly allowed standard-pair fallback.
- Expose `allowedPermissionProfiles` through `configRequirements/read`
and regenerate its schemas.
- Add regression coverage for map composition and revocation, managed
defaults, strict denial of omitted built-ins, and API output.
## Verification
- Focused `codex-config` coverage for layered map composition and
revocation
- Focused `codex-core` coverage for managed defaults, invalid defaults,
strict denial of omitted built-ins, and the standard built-in pair
- Focused `codex-app-server` coverage for requirements API output
- Scoped Clippy for `codex-config`, `codex-core`,
`codex-app-server-protocol`, and `codex-app-server`
## Documentation
The managed `requirements.toml` documentation should introduce
`allowed_permission_profiles` as a closed permission-profile allowlist
before this setting is published on developers.openai.com.
---------
Co-authored-by: Codex <noreply@openai.com>
## Summary
PR 2 of 5 in the cloud-managed config client stack.
Adds a shared requirements-layer composition engine. The composer
defines how ordered requirements layers combine, with focused tests for
the merge semantics and provenance behavior. The final PR in the stack
wires runtime requirements sources into this path.
## Details
- Mental model: requirements layers are ordered lowest priority first,
matching `ConfigLayerStack`; lower-priority layers provide defaults
while higher-priority layers win scalar/list conflicts.
- Regular fields use config-style TOML merging, including recursive
table merging, so requirements layering follows the same broad model as
`config.toml` layering.
- Domain-specific fields keep explicit semantics: `rules.prefix_rules`
and hooks preserve high-priority-first output, hooks fail closed on
active managed-dir conflicts, and `permissions.filesystem.deny_read`
dedupes as a stable high-priority-first union.
- `remote_sandbox_config` is evaluated within each layer before the
regular TOML merge, so host-specific sandbox constraints do not leak
across layers.
- Provenance points at the exact source when one layer owns a value and
uses composite provenance when a table field is assembled from multiple
layers.
## Validation
Local validation:
- `just fmt`
- `cargo check -p codex-config`
- `just test -p codex-config requirements_composition`
- `git diff --check`
CI will run the broader test matrix.
viyatb-oai