37 Commits

• Add cloud-managed config layer support (#24620)

  ## Summary
  
  PR 3 of 5 in the cloud-managed config client stack.
  
  Adds enterprise-managed cloud config as a first-class config layer
  source. The layer metadata is preserved through config loading,
  diagnostics, debug output, hook attribution, and app-server protocol
  surfaces.
  
  ## Details
  
  - Enterprise-managed config becomes a normal config layer source with
  backend-supplied `id` and display `name` attached for provenance.
  - These layers are designed to behave like non-file managed config: they
  can surface syntax/type diagnostics by layer name even though there is
  no physical config file.
  - Relative path settings are resolved from a stored config base so
  cloud-delivered config remains consistent with existing MDM-delivered
  config semantics.
  - Hook attribution distinguishes config-delivered hooks from
  requirements-delivered hooks via `HookSource::CloudManagedConfig`.
  - This remains pull-based and snapshot-oriented; the PR adds layer
  identity/diagnostics, not dynamic reload behavior.
  
  ## Validation
  
  Validated through the targeted stack checks after rebasing onto current
  `main`:
  
  - Rust crate tests for
  config/hooks/cloud-config/backend-client/app-server-protocol
  - Filtered `codex-core` and `codex-app-server` `cloud_config_bundle`
  tests
  - Python generated-file contract test
  - `cargo shear --deny-warnings`
  - Targeted `argument-comment-lint` for config/hooks

  joeflorencio-openai · 2026-05-31 15:54:31 -07:00
  8a556296f0
• Compose requirements layers (#24619)

  ## 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.

  joeflorencio-openai · 2026-05-31 15:14:06 -07:00
  20debf746b
• Constrain Windows sandbox requirements (#23766)

  # Why
  
  Managed requirements can already constrain sandbox policy choices, but
  Windows sandbox implementation selection was still resolved
  independently from those requirements. That left the TUI able to
  continue through the unelevated fallback even when an organization wants
  to require the elevated Windows sandbox implementation.
  
  # What
  
  - Add `[windows].allowed_sandbox_implementations` requirements support
  for the Windows `elevated` and `unelevated` implementations.
  - Apply that allowlist during core config resolution so disallowed
  configured or feature-selected Windows sandbox implementations fall back
  to an allowed implementation with the existing requirements warning
  path.
  - Reuse the existing TUI Windows setup prompts to block disallowed
  unelevated continuation, keep required elevated setup in front of the
  user, and refuse to persist a TUI-selected Windows sandbox mode that
  requirements disallow.
  
  # Semantics
  
  | Allowed | Selected | Effective |
  | --- | --- | --- |
  | `["elevated"]` | `unelevated` / unset | `elevated` |
  | `["unelevated"]` | `elevated` / unset | `unelevated` |
  | `["elevated", "unelevated"]` | `elevated` | `elevated` |
  | `["elevated", "unelevated"]` | `unelevated` | `unelevated` |
  | `["elevated", "unelevated"]` | unset | `elevated` |
  
  Availability is handled by interactive setup surfaces after allowlist
  resolution. If the effective elevated implementation is not ready,
  elevated-only requirements block on setup. When unelevated is also
  allowed, the UI may offer the existing unelevated fallback.
  
  ## TUI Screens
  
  If elevated setup is not already complete:
  ```
    Your organization requires the default Codex agent sandbox to continue. Set it up to protect your files and control
    network access.
    Learn more <https://developers.openai.com/codex/windows>
  
  › 1. Set up default sandbox (requires Administrator permissions)
    2. Quit
  ```
  
  If admin setup fails under `["elevated"]`:
  ```
    Couldn't set up your sandbox with Administrator permissions
  
    Your organization requires the default sandbox before Codex can continue.
    Learn more <https://developers.openai.com/codex/windows>
  
  › 1. Try setting up admin sandbox again
    2. Quit
  ```
  
  # Next Steps
  
  
  - extend the requirements/readout surface, such as
  `configRequirements/read`, so clients can inspect the loaded
  `[windows].allowed_sandbox_implementations` requirement instead of
  inferring it from Windows setup state
  - consider extending `windowsSandbox/readiness` as well
  - update the App startup guide, setup flow, and banner surfaces so an
  elevated-only requirement omits any continue-unelevated escape hatch and
  blocks startup until a permitted implementation is ready;
  - preserve the existing unelevated fallback path when requirements allow
  it, including the `["unelevated"]` case where elevated is disallowed

  Abhinav · 2026-05-29 16:31:33 -07:00
  a5a94ee5a7
• Route MCP servers through explicit environments (#23583)

  ## Summary
  - route each configured MCP server through an explicit per-server
  `environment_id` instead of a manager-wide remote toggle
  - default omitted `environment_id` to `local`, resolve named ids through
  `EnvironmentManager`, and fail only the affected MCP server when an
  explicit id is unknown
  - keep local stdio on the existing local launcher path for now, while
  named-environment stdio uses the selected environment backend and
  requires an absolute `cwd`
  - allow local HTTP MCP servers to keep using the ambient HTTP client
  when no local `Environment` is configured; named-environment HTTP MCPs
  use that environment's HTTP client
  
  ## Validation
  - devbox Bazel build: `bazel build --bes_backend= --bes_results_url=
  //codex-rs/cli:codex //codex-rs/rmcp-client:test_stdio_server
  //codex-rs/rmcp-client:test_streamable_http_server`
  - devbox app-server config matrix with real `config.toml` /
  `environments.toml` files covering omitted local, explicit local,
  omitted local under remote default, explicit remote stdio, local HTTP
  without local env, explicit remote HTTP, local stdio without local env,
  unknown explicit env, and remote stdio without `cwd`

  starr-openai · 2026-05-21 17:19:54 +02:00
  298e5cfce1
• Add CUA requirements subsection for locked computer use (#23555)

  Adds a new top-level section for "CUA" requirements that can allow for
  disablement of specific features as needed for enterprises.

  adams-oai · 2026-05-19 15:41:44 -07:00
  d86352d520
• Support explicit MCP OAuth client IDs (#22575)

  ## Why
  Some MCP OAuth providers require a pre-registered public client ID and
  cannot rely on dynamic client registration. Codex already supports MCP
  OAuth, but it had no way to supply that client ID from config into the
  PKCE flow.
  
  ## What changed
  - add `oauth.client_id` under `[mcp_servers.<server>]` config, including
  config editing and schema generation
  - thread the configured client ID through CLI, app-server, plugin login,
  and MCP skill dependency OAuth entrypoints
  - configure RMCP authorization with the explicit client when present,
  while preserving the existing dynamic-registration path when it is
  absent
  - add focused coverage for config parsing/serialization and OAuth URL
  generation
  
  ## Verification
  - `cargo test -p codex-config -p codex-rmcp-client -p codex-mcp -p
  codex-core-plugins`
  - `cargo test -p codex-core blocking_replace_mcp_servers_round_trips
  --lib`
  - `cargo test -p codex-core
  replace_mcp_servers_streamable_http_serializes_oauth_resource --lib`
  - `cargo test -p codex-core config_schema_matches_fixture --lib`
  
  ## Notes
  Broader local package runs still hit unrelated pre-existing stack
  overflows in:
  - `codex-app-server::in_process_start_clamps_zero_channel_capacity`
  -
  `codex-core::resume_agent_from_rollout_uses_edge_data_when_descendant_metadata_source_is_stale`

  Matthew Zeng · 2026-05-14 11:52:43 -07:00
  d8ddeb6869
• feat: add layered --profile-v2 config files (#17141)

  ## Why
  
  `--profile-v2 <name>` gives launchers and runtime entry points a named
  profile config without making each profile duplicate the base user
  config. The base `$CODEX_HOME/config.toml` still loads first, then
  `$CODEX_HOME/<name>.config.toml` layers above it and becomes the active
  writable user config for that session.
  
  That keeps shared defaults, plugin/MCP setup, and managed/user
  constraints in one place while letting a named profile override only the
  pieces that need to differ.
  
  ## What Changed
  
  - Added the shared `--profile-v2 <name>` runtime option with validated
  plain names, now represented by `ProfileV2Name`.
  - Extended config layer state so the base user config and selected
  profile config are both `User` layers; APIs expose the active user layer
  and merged effective user config.
  - Threaded profile selection through runtime entry points: `codex`,
  `codex exec`, `codex review`, `codex resume`, `codex fork`, and `codex
  debug prompt-input`.
  - Made user-facing config writes go to the selected profile file when
  active, including TUI/settings persistence, app-server config writes,
  and MCP/app tool approval persistence.
  - Made plugin, marketplace, MCP, hooks, and config reload paths read
  from the merged user config so base and profile layers both participate.
  - Updated app-server config layer schemas to mark profile-backed user
  layers.
  
  ## Limits
  
  `--profile-v2` is still rejected for config-management subcommands such
  as feature, MCP, and marketplace edits. Those paths remain tied to the
  base `config.toml` until they have explicit profile-selection semantics.
  
  Some adjacent background writes may still update base or global state
  rather than the selected profile:
  
  - marketplace auto-upgrade metadata
  - automatic MCP dependency installs from skills
  - remote plugin sync or uninstall config edits
  - personality migration marker/default writes
  
  ## Verification
  
  Added targeted coverage for profile name validation, layer
  ordering/merging, selected-profile writes, app-server config writes,
  session hot reload, plugin config merging, hooks/config fixture updates,
  and MCP/app approval persistence.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-14 15:16:15 +02:00
  deedf3b2c4
• config: add strict config parsing (#20559)

  ## Why
  
  Codex intentionally ignores unknown `config.toml` fields by default so
  older and newer config files keep working across versions. That leniency
  also makes typo detection hard because misspelled or misplaced keys
  disappear silently.
  
  This change adds an opt-in strict config mode so users and tooling can
  fail fast on unrecognized config fields without changing the default
  permissive behavior.
  
  This feature is possible because `serde_ignored` exposes the exact
  signal Codex needs: it lets Codex run ordinary Serde deserialization
  while recording fields Serde would otherwise ignore. That avoids
  requiring `#[serde(deny_unknown_fields)]` across every config type and
  keeps strict validation opt-in around the existing config model.
  
  ## What Changed
  
  ### Added strict config validation
  
  - Added `serde_ignored`-based validation for `ConfigToml` in
  `codex-rs/config/src/strict_config.rs`.
  - Combined `serde_ignored` with `serde_path_to_error` so strict mode
  preserves typed config error paths while also collecting fields Serde
  would otherwise ignore.
  - Added strict-mode validation for unknown `[features]` keys, including
  keys that would otherwise be accepted by `FeaturesToml`'s flattened
  boolean map.
  - Kept typed config errors ahead of ignored-field reporting, so
  malformed known fields are reported before unknown-field diagnostics.
  - Added source-range diagnostics for top-level and nested unknown config
  fields, including non-file managed preference source names.
  
  ### Kept parsing single-pass per source
  
  - Reworked file and managed-config loading so strict validation reuses
  the already parsed `TomlValue` for that source.
  - For actual config files and managed config strings, the loader now
  reads once, parses once, and validates that same parsed value instead of
  deserializing multiple times.
  - Validated `-c` / `--config` override layers with the same
  base-directory context used for normal relative-path resolution, so
  unknown override keys are still reported when another override contains
  a relative path.
  
  ### Scoped `--strict-config` to config-heavy entry points
  
  - Added support for `--strict-config` on the main config-loading entry
  points where it is most useful:
    - `codex`
    - `codex resume`
    - `codex fork`
    - `codex exec`
    - `codex review`
    - `codex mcp-server`
    - `codex app-server` when running the server itself
    - the standalone `codex-app-server` binary
    - the standalone `codex-exec` binary
  - Commands outside that set now reject `--strict-config` early with
  targeted errors instead of accepting it everywhere through shared CLI
  plumbing.
  - `codex app-server` subcommands such as `proxy`, `daemon`, and
  `generate-*` are intentionally excluded from the first rollout.
  - When app-server strict mode sees invalid config, app-server exits with
  the config error instead of logging a warning and continuing with
  defaults.
  - Introduced a dedicated `ReviewCommand` wrapper in `codex-rs/cli`
  instead of extending shared `ReviewArgs`, so `--strict-config` stays on
  the outer config-loading command surface and does not become part of the
  reusable review payload used by `codex exec review`.
  
  ### Coverage
  
  - Added tests for top-level and nested unknown config fields, unknown
  `[features]` keys, typed-error precedence, source-location reporting,
  and non-file managed preference source names.
  - Added CLI coverage showing invalid `--enable`, invalid `--disable`,
  and unknown `-c` overrides still error when `--strict-config` is
  present, including compound-looking feature names such as
  `multi_agent_v2.subagent_usage_hint_text`.
  - Added integration coverage showing both `codex app-server
  --strict-config` and standalone `codex-app-server --strict-config` exit
  with an error for unknown config fields instead of starting with
  fallback defaults.
  - Added coverage showing unsupported command surfaces reject
  `--strict-config` with explicit errors.
  
  ## Example Usage
  
  Run Codex with strict config validation enabled:
  
  ```shell
  codex --strict-config
  ```
  
  Strict config mode is also available on the supported config-heavy
  subcommands:
  
  ```shell
  codex --strict-config exec "explain this repository"
  codex review --strict-config --uncommitted
  codex mcp-server --strict-config
  codex app-server --strict-config --listen off
  codex-app-server --strict-config --listen off
  ```
  
  For example, if `~/.codex/config.toml` contains a typo in a key name:
  
  ```toml
  model = "gpt-5"
  approval_polic = "on-request"
  ```
  
  then `codex --strict-config` reports the misspelled key instead of
  silently ignoring it. The path is shortened to `~` here for readability:
  
  ```text
  $ codex --strict-config
  Error loading config.toml:
  ~/.codex/config.toml:2:1: unknown configuration field `approval_polic`
    |
  2 | approval_polic = "on-request"
    | ^^^^^^^^^^^^^^
  ```
  
  Without `--strict-config`, Codex keeps the existing permissive behavior
  and ignores the unknown key.
  
  Strict config mode also validates ad-hoc `-c` / `--config` overrides:
  
  ```text
  $ codex --strict-config -c foo=bar
  Error: unknown configuration field `foo` in -c/--config override
  
  $ codex --strict-config -c features.foo=true
  Error: unknown configuration field `features.foo` in -c/--config override
  ```
  
  Invalid feature toggles are rejected too, including values that look
  like nested config paths:
  
  ```text
  $ codex --strict-config --enable does_not_exist
  Error: Unknown feature flag: does_not_exist
  
  $ codex --strict-config --disable does_not_exist
  Error: Unknown feature flag: does_not_exist
  
  $ codex --strict-config --enable multi_agent_v2.subagent_usage_hint_text
  Error: Unknown feature flag: multi_agent_v2.subagent_usage_hint_text
  ```
  
  Unsupported commands reject the flag explicitly:
  
  ```text
  $ codex --strict-config cloud list
  Error: `--strict-config` is not supported for `codex cloud`
  ```
  
  ## Verification
  
  The `codex-cli` `strict_config` tests cover invalid `--enable`, invalid
  `--disable`, the compound `multi_agent_v2.subagent_usage_hint_text`
  case, unknown `-c` overrides, app-server strict startup failure through
  `codex app-server`, and rejection for unsupported commands such as
  `codex cloud`, `codex mcp`, `codex remote-control`, and `codex
  app-server proxy`.
  
  The config and config-loader tests cover unknown top-level fields,
  unknown nested fields, unknown `[features]` keys, source-location
  reporting, non-file managed config sources, and `-c` validation for keys
  such as `features.foo`.
  
  The app-server test suite covers standalone `codex-app-server
  --strict-config` startup failure for an unknown config field.
  
  ## Documentation
  
  The Codex CLI docs on developers.openai.com/codex should mention
  `--strict-config` as an opt-in validation mode for supported
  config-heavy entry points once this ships.

  Michael Bolin · 2026-05-13 16:08:05 +00:00
  889ee018e7
• feat(connectors): support managed app tool approval requirements (#21061)

  ## Why
  
  Managed requirements can already centrally disable apps, but they could
  not express the per-tool app approval rules that normal config already
  supports. That left admins without a way to enforce connector tool
  approvals through `/etc/codex/requirements.toml` or cloud requirements.
  
  ## What changed
  
  - Extend app requirements with per-tool `approval_mode` entries.
  - Merge managed app tool requirements across managed sources while
  preserving higher-precedence exact tool settings.
  - Apply managed tool approvals separately from user app config so
  managed policy is matched only on raw MCP `tool.name`, while user config
  keeps the existing raw-name-then-title convenience fallback.
  - Add coverage for local requirements, cloud requirements parsing,
  managed-over-user precedence, and a title-collision case that must not
  widen managed auto-approval.
  
  ## Configuration shape
  
  Local `/etc/codex/requirements.toml` and cloud requirements use the same
  TOML shape:
  
  ```toml
  [apps.connector_123123.tools."calendar/list_events"]
  approval_mode = "approve"
  ```
  
  This is a per-tool approval rule keyed by app ID and raw MCP tool name,
  not an app-level boolean such as `apps.connector_123123.approve = true`.

  viyatb-oai · 2026-05-11 19:08:26 +00:00
  d0fa2d81d8
• Move plugin out of core. (#20348)
  xl-openai · 2026-04-30 14:26:14 -07:00
  7b3de63041
• Add persisted hook enablement state (#19840)

  ## Why
  
  After `hooks/list` exposes the hook inventory, clients need a way to
  persist user hook preferences, make those changes effective in
  already-open sessions, and distinguish user-controllable hooks from
  managed requirements without adding another bespoke app-server write
  API.
  
  ## What
  
  - Extends `hooks/list` entries with effective `enabled` state.
  - Persists user-level hook state under `hooks.state.<hook-id>` so the
  model can grow beyond a single boolean over time.
  - Uses the existing `config/batchWrite` path for hook state updates
  instead of introducing a dedicated hook write RPC.
  - Refreshes live session hook engines after config writes so
  already-open threads observe updated enablement without a restart.
  
  ## Stack
  
  1. openai/codex#19705
  2. openai/codex#19778
  3. This PR - openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  The generated schema files account for much of the raw diff. The core
  behavior is in:
  
  - `hooks/src/config_rules.rs`, which resolves per-hook user state from
  the config layer stack.
  - `hooks/src/engine/discovery.rs`, which projects effective enablement
  into `hooks/list` from source-derived managedness.
  - `config/src/hook_config.rs`, which defines the new `hooks.state`
  representation.
  - `core/src/session/mod.rs`, which rebuilds live hook state after user
  config reloads.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-30 04:46:32 +00:00
  8f3c06cc97
• [mcp] Fix plugin MCP approval policy. (#19537)

  Plugin MCP servers are loaded from plugin manifests rather than
  top-level `[mcp_servers]`, so their tool approval preferences need to be
  stored and applied through the owning plugin config. Without this,
  choosing "Always allow" for a plugin MCP tool could write a preference
  that was not reliably used on later tool calls.
  
  ## Summary
  - Add plugin-scoped MCP policy config under
  `plugins.<plugin>.mcp_servers`, including server enablement, tool
  allow/deny lists, server defaults, and per-tool approval modes.
  - Overlay plugin MCP policy onto manifest-provided server configs when
  plugins are loaded.
  - Route persistent "Always allow" writes for plugin MCP tools back to
  the owning `plugins.<plugin>.mcp_servers.<server>.tools.<tool>` config
  entry.
  - Reload user config after persisting an approval and make the plugin
  load cache config-aware so stale plugin MCP policy is not reused after
  `config.toml` changes.
  - Regenerate the config schema and add coverage for plugin MCP policy
  loading, approval lookup, persistence, and stale-cache prevention.
  
  ## Testing
  - `cargo test -p codex-config`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-core --lib plugin_mcp`

  Matthew Zeng · 2026-04-29 15:40:03 -07:00
  e20391e567
• feat(tui): add configurable keymap support (#18593)

  ## Why
  
  The TUI currently handles keyboard shortcuts as hard-coded event matches
  spread across app, composer, pager, list, approval, and navigation code.
  That makes shortcuts hard to customize, makes displayed hints easy to
  drift from actual behavior, and makes future keymap work riskier because
  there is no central action inventory.
  
  This PR adds the foundation for configurable, action-based keymaps
  without adding the interactive remapping UI yet. Onboarding
  intentionally stays on fixed startup shortcuts because users cannot
  reasonably configure keymaps before completing onboarding.
  
  This is PR1 in the keymap stack:
  
  - PR1: #18593: configurable keymap foundation
  - PR2: #18594: `/keymap` picker and guided remapping UI
  - PR3: #18595: Vim composer mode and the remap option
  
  ## Design Notes
  
  The new model resolves named actions into concrete runtime bindings once
  from config, then passes those bindings to the UI surfaces that handle
  input or render shortcut hints.
  
  The main concepts are:
  
  - **Context**: a scope where an action is active, such as `global`,
  `chat`, `composer`, `editor`, `pager`, `list`, or `approval`.
  - **Action**: a named operation inside a context, such as
  `global.open_transcript`, `composer.submit`, or `pager.close`.
  - **Binding**: one or more single-key shortcuts assigned to an action,
  written as config strings such as `ctrl-t`, `alt-backspace`, or
  `page-down`. Multi-step sequences such as `ctrl-x ctrl-s`, `g g`, or
  leader-key flows are not part of this PR.
  - **Resolution order**: context-specific config wins first, supported
  global fallbacks come next, and built-in defaults fill in anything
  unset.
  - **Explicit unbinding**: an empty array removes an action binding in
  that scope and does not fall through to a fallback binding.
  - **Conflict validation**: a resolved keymap rejects duplicate active
  bindings inside the same scope so one keypress cannot dispatch two
  actions.
  
  ## What Changed
  
  - Added `TuiKeymap` config support under `[tui.keymap]`, including typed
  contexts/actions, key alias normalization, generated schema coverage,
  and user-facing config errors.
  - Added `RuntimeKeymap` resolution in `codex-rs/tui/src/keymap.rs`,
  including fallback precedence, built-in defaults, explicit unbinding,
  and per-context conflict validation.
  - Rewired existing TUI handlers to consume resolved keymap actions
  instead of directly matching hard-coded keys in each component.
  - Updated key hint rendering and footer/pager/list surfaces so displayed
  shortcuts follow the resolved keymap.
  - Kept onboarding shortcuts fixed in
  `codex-rs/tui/src/onboarding/keys.rs` instead of exposing them through
  `[tui.keymap]`.
  
  ## Validation
  
  The branch includes focused coverage for config parsing, key
  normalization, runtime fallback resolution, explicit unbinding,
  duplicate-key conflict validation, default keymap consistency,
  onboarding startup key behavior, and UI hint snapshots affected by
  resolved key bindings.

  Felipe Coury · 2026-04-28 12:52:25 -03:00
  5e737372ee
• permissions: constrain requirements as profiles (#19736)
  Michael Bolin · 2026-04-26 21:49:30 -07:00
  523e4aa8e3
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• Add remote thread config loader protos (#18892)

  ## Why
  
  Thread-scoped config needs a stable boundary between the app/session
  owner and the config stack. Instead of having call sites manually copy
  thread config fields into individual overrides, this adds the proto and
  Rust plumbing needed for a `ThreadConfigLoader` implementation to return
  typed sources that can be translated into ordinary config layer entries.
  
  Keeping the remote payload typed also makes precedence easier to reason
  about: session-owned thread config maps back to the existing session
  config source, while user-owned thread config is represented separately
  without introducing a new config-layer source until it has TOML-backed
  fields.
  
  ## What changed
  
  - Added the `codex.thread_config.v1` protobuf service and generated Rust
  module for loading thread config sources.
  - Added `RemoteThreadConfigLoader`, which calls the gRPC service, parses
  `SessionThreadConfig` / `UserThreadConfig`, and validates provider
  fields such as `wire_api`, auth timeout, and absolute auth cwd.
  - Added proto generation tooling under
  `config/scripts/generate-proto.sh` and
  `config/examples/generate-proto.rs`.
  - Added `ThreadConfigLoader::load_config_layers`, plus static/no-op
  loader helpers, so tests and callers can use the same typed loader
  interface while config-layer translation stays centralized.
  
  ## Verification
  
  - `cargo test -p codex-config thread_config`

  Rasmus Rygaard · 2026-04-23 10:06:05 -07:00
  0b4f694347
• codex: support hooks in config.toml and requirements.toml (#18893)

  ## Summary
  
  Support the existing hooks schema in inline TOML so hooks can be
  configured from both `config.toml` and enterprise-managed
  `requirements.toml` without requiring a separate `hooks.json` payload.
  
  This gives enterprise admins a way to ship managed hook policy through
  the existing requirements channel while still leaving script delivery to
  MDM or other device-management tooling, and it keeps `hooks.json`
  working unchanged for existing users.
  
  This also lays the groundwork for follow-on managed filtering work such
  as #15937, while continuing to respect project trust gating from #14718.
  It does **not** implement `allow_managed_hooks_only` itself.
  
  NOTE: yes, it's a bit unfortunate that the toml isn't formatted as
  closely as normal to our default styling. This is because we're trying
  to stay compatible with the spec for plugins/hooks that we'll need to
  support & the main usecase here is embedding into requirements.toml
  
  ## What changed
  
  - moved the shared hook serde model out of `codex-rs/hooks` into
  `codex-rs/config` so the same schema can power `hooks.json`, inline
  `config.toml` hooks, and managed `requirements.toml` hooks
  - added `hooks` support to both `ConfigToml` and
  `ConfigRequirementsToml`, including requirements-side `managed_dir` /
  `windows_managed_dir`
  - treated requirements-managed hooks as one constrained value via
  `Constrained`, so managed hook policy is merged atomically and cannot
  drift across requirement sources
  - updated hook discovery to load requirements-managed hooks first, then
  per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning
  when a single layer defines both representations
  - threaded managed hook metadata through discovered handlers and exposed
  requirements hooks in app-server responses, generated schemas, and
  `/debug-config`
  - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`,
  `codex-rs/core/src/config_loader/tests.rs`, and
  `codex-rs/core/tests/suite/hooks.rs`
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server config_api`
  
  ## Documentation
  
  Companion updates are needed in the developers website repo for:
  
  - the hooks guide
  - the config reference, sample, basic, and advanced pages
  - the enterprise managed configuration guide
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Andrei Eternal · 2026-04-22 21:20:09 -07:00
  2b2de3f38b
• Add remote_sandbox_config to our config requirements (#18763)

  ## Why
  
  Customers need finer-grained control over allowed sandbox modes based on
  the host Codex is running on. For example, they may want stricter
  sandbox limits on devboxes while keeping a different default elsewhere.
  
  Our current cloud requirements can target user/account groups, but they
  cannot vary sandbox requirements by host. That makes remote development
  environments awkward because the same top-level `allowed_sandbox_modes`
  has to apply everywhere.
  
  ## What
  
  Adds a new `remote_sandbox_config` section to `requirements.toml`:
  
  ```toml
  allowed_sandbox_modes = ["read-only"]
  
  [[remote_sandbox_config]]
  hostname_patterns = ["*.org"]
  allowed_sandbox_modes = ["read-only", "workspace-write"]
  
  [[remote_sandbox_config]]
  hostname_patterns = ["*.sh", "runner-*.ci"]
  allowed_sandbox_modes = ["read-only", "danger-full-access"]
  ```
  
  During requirements resolution, Codex resolves the local host name once,
  preferring the machine FQDN when available and falling back to the
  cleaned kernel hostname. This host classification is best effort rather
  than authenticated device proof.
  
  Each requirements source applies its first matching
  `remote_sandbox_config` entry before it is merged with other sources.
  The shared merge helper keeps that `apply_remote_sandbox_config` step
  paired with requirements merging so new requirements sources do not have
  to remember the extra call.
  
  That preserves source precedence: a lower-precedence requirements file
  with a matching `remote_sandbox_config` cannot override a
  higher-precedence source that already set `allowed_sandbox_modes`.
  
  This also wires the hostname-aware resolution through app-server,
  CLI/TUI config loading, config API reads, and config layer metadata so
  they all evaluate remote sandbox requirements consistently.
  
  ## Verification
  
  - `cargo test -p codex-config remote_sandbox_config`
  - `cargo test -p codex-config host_name`
  - `cargo test -p codex-core
  load_config_layers_applies_matching_remote_sandbox_config`
  - `cargo test -p codex-core
  system_remote_sandbox_config_keeps_cloud_sandbox_modes`
  - `cargo test -p codex-config`
  - `cargo test -p codex-core` unit tests passed; `tests/all.rs`
  integration matrix was intentionally stopped after the relevant focused
  tests passed
  - `just fix -p codex-config`
  - `just fix -p codex-core`
  - `cargo check -p codex-app-server`

  Abhinav · 2026-04-21 05:05:02 +00:00
  ab26554a3a
• Add session config loader interface (#18208)

  ## Why
  
  Cloud-hosted sessions need a way for the service that starts or manages
  a thread to provide session-owned config without treating all config as
  if it came from the same user/project/workspace TOML stack.
  
  The important boundary is ownership: some values should be controlled by
  the session/orchestrator, some by the authenticated user, and later some
  may come from the executor. The earlier broad config-store shape made
  that boundary too fuzzy and overlapped heavily with the existing
  filesystem-backed config loader. This PR starts with the smaller piece
  we need now: a typed session config loader that can feed the existing
  config layer stack while preserving the normal precedence and merge
  behavior.
  
  ## What Changed
  
  - Added `ThreadConfigLoader` and related typed payloads in
  `codex-config`.
  - `SessionThreadConfig` currently supports `model_provider`,
  `model_providers`, and feature flags.
  - `UserThreadConfig` is present as an ownership boundary, but does not
  yet add TOML-backed fields.
  - `NoopThreadConfigLoader` preserves existing behavior when no external
  loader is configured.
    - `StaticThreadConfigLoader` supports tests and simple callers.
  
  - Taught thread config sources to produce ordinary `ConfigLayerEntry`
  values so the existing `ConfigLayerStack` remains the place where
  precedence and merging happen.
  
  - Wired the loader through `ConfigBuilder`, the config loader, and
  app-server startup paths so app-server can provide session-owned config
  before deriving a thread config.
  
  - Added coverage for:
    - translating typed thread config into config layers,
  - inserting thread config layers into the stack at the right precedence,
  - applying session-provided model provider and feature settings when
  app-server derives config from thread params.
  
  ## Follow-Ups
  
  This intentionally stops short of adding the remote/service transport.
  The next pieces are expected to be:
  
  1. Define the proto/API shape for this interface.
  2. Add a client implementation that can source session config from the
  service side.
  
  ## Verification
  
  - Added unit coverage in `codex-config` for the loader and layer
  conversion.
  - Added `codex-core` config loader coverage for thread config layer
  precedence.
  - Added app-server coverage that verifies session thread config wins
  over request-provided config for model provider and feature settings.

  Rasmus Rygaard · 2026-04-20 23:05:49 +00:00
  7b994100b3
• [5/6] Wire executor-backed MCP stdio (#18212)

  ## Summary
  - Add the executor-backed RMCP stdio transport.
  - Wire MCP stdio placement through the executor environment config.
  - Cover local and executor-backed stdio paths with the existing MCP test
  helpers.
  
  ## Stack
  ```text
  o  #18027 [6/6] Fail exec client operations after disconnect
  │
  @  #18212 [5/6] Wire executor-backed MCP stdio
  │
  o  #18087 [4/6] Abstract MCP stdio server launching
  │
  o  #18020 [3/6] Add pushed exec process events
  │
  o  #18086 [2/6] Support piped stdin in exec process API
  │
  o  #18085 [1/6] Add MCP server environment config
  │
  o  main
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-18 21:47:43 -07:00
  996aa23e4c
• [codex] Add marketplace remove command and shared logic (#17752)

  ## Summary
  
  Move the marketplace remove implementation into shared core logic so
  both the CLI command and follow-up app-server RPC can reuse the same
  behavior.
  
  This change:
  - adds a shared `codex_core::plugins::remove_marketplace(...)` flow
  - moves validation, config removal, and installed-root deletion out of
  the CLI
  - keeps the CLI as a thin wrapper over the shared implementation
  - adds focused core coverage for the shared remove path
  
  ## Validation
  
  - `just fmt`
  - focused local coverage for the shared remove path
  - heavier follow-up validation deferred to stacked PR CI

  xli-oai · 2026-04-17 21:44:47 -07:00
  e9c70fff3f
• feat: config aliases (#18140)

  Rename `no_memories_if_mcp_or_web_search` →
  `disable_on_external_context` with backward compatibility
  
  While doing so, we add a key alias system on our layer merging system.
  What we try to avoid is a case where a company managed config use an old
  name while the user has a new name in it's local config (which would
  make the deserialization fail)

  jif-oai · 2026-04-17 18:26:09 +01:00
  cfc23eee3d
• feat(config): support managed deny-read requirements (#17740)

  ## Summary
  - adds managed requirements support for deny-read filesystem entries
  - constrains config layers so managed deny-read requirements cannot be
  widened by user-controlled config
  - surfaces managed deny-read requirements through debug/config plumbing
  
  This PR lets managed requirements inject deny-read filesystem
  constraints into the effective filesystem sandbox policy.
  User-controlled config can still choose the surrounding permission
  profile, but it cannot remove or weaken the managed deny-read entries.
  
  ## Managed deny-read shape
  A managed requirements file can declare exact paths and glob patterns
  under `[permissions.filesystem]`:
  
  ```toml
  # /etc/codex/requirements.toml
  [permissions.filesystem]
  deny_read = [
    "/Users/alice/.gitconfig",
    "/Users/alice/.ssh",
    "./managed-private/**/*.env",
  ]
  ```
  
  Those entries are compiled into the effective filesystem policy as
  `access = none` rules, equivalent in shape to filesystem permission
  entries like:
  
  ```toml
  [permissions.workspace.filesystem]
  "/Users/alice/.gitconfig" = "none"
  "/Users/alice/.ssh" = "none"
  "/absolute/path/to/managed-private/**/*.env" = "none"
  ```
  
  The important difference is that the managed entries come from
  requirements, so lower-precedence user config cannot remove them or make
  those paths readable again.
  
  Relative managed `deny_read` entries are resolved relative to the
  directory containing the managed requirements file. Glob entries keep
  their glob suffix after the non-glob prefix is normalized.
  
  ## Runtime behavior
  - Managed `deny_read` entries are appended to the effective
  `FileSystemSandboxPolicy` after the selected permission profile is
  resolved.
  - Exact paths become `FileSystemPath::Path { access: None }`; glob
  patterns become `FileSystemPath::GlobPattern { access: None }`.
  - When managed deny-read entries are present, `sandbox_mode` is
  constrained to `read-only` or `workspace-write`; `danger-full-access`
  and `external-sandbox` cannot silently bypass the managed read-deny
  policy.
  - On Windows, the managed deny-read policy is enforced for direct file
  tools, but shell subprocess reads are not sandboxed yet, so startup
  emits a warning for that platform.
  - `/debug-config` shows the effective managed requirement as
  `permissions.filesystem.deny_read` with its source.
  
  ## Stack
  1. #15979 - glob deny-read policy/config/direct-tool support
  2. #18096 - macOS and Linux sandbox enforcement
  3. This PR - managed deny-read requirements
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-17 08:40:09 -07:00
  dae0608c06
• Add codex_hook_run analytics event (#17996)

  # Why
  Add product analytics for hook handler executions so we can understand
  which hooks are running, where they came from, and whether they
  completed, failed, stopped, or blocked work.
  
  # What
  - add the new `codex_hook_run` analytics event and payload plumbing in
  `codex-rs/analytics`
  - emit hook-run analytics from the shared hook completion path in
  `codex-rs/core`
  - classify hook source from the loaded hook path as `system`, `user`,
  `project`, or `unknown`
  
  ```
  {
    "event_type": "codex_hook_run",
    "event_params": {
      "thread_id": "string",
      "turn_id": "string",
      "model_slug": "string",
      "hook_name": "string, // any HookEventName
      "hook_source": "system | user | project | unknown",
      "status": "completed | failed | stopped | blocked"
    }
  }
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-16 19:43:16 +00:00
  8720b7bdce
• Build remote exec env from exec-server policy (#17216)

  ## Summary
  - add an exec-server `envPolicy` field; when present, the server starts
  from its own process env and applies the shell environment policy there
  - keep `env` as the exact environment for local/embedded starts, but
  make it an overlay for remote unified-exec starts
  - move the shell-environment-policy builder into `codex-config` so Core
  and exec-server share the inherit/filter/set/include behavior
  - overlay only runtime/sandbox/network deltas from Core onto the
  exec-server-derived env
  
  ## Why
  Remote unified exec was materializing the shell env inside Core and
  forwarding the whole map to exec-server, so remote processes could
  inherit the orchestrator machine's `HOME`, `PATH`, etc. This keeps the
  base env on the executor while preserving Core-owned runtime additions
  like `CODEX_THREAD_ID`, unified-exec defaults, network proxy env, and
  sandbox marker env.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - `cargo test -p codex-exec-server --lib`
  - `cargo test -p codex-core --lib unified_exec::process_manager::tests`
  - `cargo test -p codex-core --lib exec_env::tests`
  - `cargo test -p codex-core --lib exec_env_tests` (compile-only; filter
  matched 0 tests)
  - `cargo test -p codex-config --lib shell_environment` (compile-only;
  filter matched 0 tests)
  - `just bazel-lock-update`
  
  ## Known local validation issue
  - `just bazel-lock-check` is not runnable in this checkout: it invokes
  `./scripts/check-module-bazel-lock.sh`, which is missing.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  jif-oai · 2026-04-13 09:59:08 +01:00
  bacb92b1d7
• Add marketplace command (#17087)

  Added a new top-level `codex marketplace add` command for installing
  plugin marketplaces into Codex’s local marketplace cache.
  
  This change adds source parsing for local directories, GitHub shorthand,
  and git URLs, supports optional `--ref` and git-only `--sparse` checkout
  paths, stages the source in a temp directory, validates the marketplace
  manifest, and installs it under
  `$CODEX_HOME/marketplaces/<marketplace-name>`
  
  Included tests cover local install behavior in the CLI and marketplace
  discovery from installed roots in core. Scoped formatting and fix passes
  were run, and targeted CLI/core tests passed.

  xli-oai · 2026-04-10 19:18:37 -07:00
  f9a8d1870f
• Refactor config types into a separate crate (#16962)

  Move config types into a separate crate because their macros expand into
  a lot of new code.

  pakrym-oai · 2026-04-07 00:32:41 +00:00
  1f2411629f
• [codex] Move config types into codex-config (#16523)

  ## Why
  
  `codex-rs/core/src/config/types.rs` is a plain config-type module with
  no dependency on `codex-core`. Moving it into `codex-config` shrinks the
  core crate and gives config-only consumers a more natural dependency
  boundary.
  
  ## What Changed
  
  - Added `codex_config::types` with the moved structs, enums, constants,
  and unit tests.
  - Kept `codex_core::config::types` as a compatibility re-export to avoid
  a broad call-site migration in this PR.
  - Switched notice-table writes in `core/src/config/edit.rs` to a local
  `NOTICE_TABLE_KEY` constant.
  - Added the `wildmatch` runtime dependency and `tempfile` test
  dependency to `codex-config`.

  Michael Bolin · 2026-04-02 00:39:20 -07:00
  f32a5e84bf
• Extract MCP into codex-mcp crate (#15919)

  - Split MCP runtime/server code out of `codex-core` into the new
  `codex-mcp` crate. New/moved public structs/types include `McpConfig`,
  `McpConnectionManager`, `ToolInfo`, `ToolPluginProvenance`,
  `CodexAppsToolsCacheKey`, and the `McpManager` API
  (`codex_mcp::mcp::McpManager` plus the `codex_core::mcp::McpManager`
  wrapper/shim). New/moved functions include `with_codex_apps_mcp`,
  `configured_mcp_servers`, `effective_mcp_servers`,
  `collect_mcp_snapshot`, `collect_mcp_snapshot_from_manager`,
  `qualified_mcp_tool_name_prefix`, and the MCP auth/skill-dependency
  helpers. Why: this creates a focused MCP crate boundary and shrinks
  `codex-core` without forcing every consumer to migrate in the same PR.
  
  - Move MCP server config schema and persistence into `codex-config`.
  New/moved structs/enums include `AppToolApproval`,
  `McpServerToolConfig`, `McpServerConfig`, `RawMcpServerConfig`,
  `McpServerTransportConfig`, `McpServerDisabledReason`, and
  `codex_config::ConfigEditsBuilder`. New/moved functions include
  `load_global_mcp_servers` and
  `ConfigEditsBuilder::replace_mcp_servers`/`apply`. Why: MCP TOML
  parsing/editing is config ownership, and this keeps config
  validation/round-tripping (including per-tool approval overrides and
  inline bearer-token rejection) in the config crate instead of
  `codex-core`.
  
  - Rewire `codex-core`, app-server, and plugin call sites onto the new
  crates. Updated `Config::to_mcp_config(&self, plugins_manager)`,
  `codex-rs/core/src/mcp.rs`, `codex-rs/core/src/connectors.rs`,
  `codex-rs/core/src/codex.rs`,
  `CodexMessageProcessor::list_mcp_server_status_task`, and
  `utils/plugins/src/mcp_connector.rs` to build/pass the new MCP
  config/runtime types. Why: plugin-provided MCP servers still merge with
  user-configured servers, and runtime auth (`CodexAuth`) is threaded into
  `with_codex_apps_mcp` / `collect_mcp_snapshot` explicitly so `McpConfig`
  stays config-only.

  Ahmed Ibrahim · 2026-04-01 19:03:26 -07:00
  59b68f5519
• chore: refactor network permissions to use explicit domain and unix socket rule maps (#15120)

  ## Summary
  
  This PR replaces the legacy network allow/deny list model with explicit
  rule maps for domains and unix sockets across managed requirements,
  permissions profiles, the network proxy config, and the app server
  protocol.
  
  Concretely, it:
  
  - introduces typed domain (`allow` / `deny`) and unix socket permission
  (`allow` / `none`) entries instead of separate `allowed_domains`,
  `denied_domains`, and `allow_unix_sockets` lists
  - updates config loading, managed requirements merging, and exec-policy
  overlays to read and upsert rule entries consistently
  - exposes the new shape through protocol/schema outputs, debug surfaces,
  and app-server config APIs
  - rejects the legacy list-based keys and updates docs/tests to reflect
  the new config format
  
  ## Why
  
  The previous representation split related network policy across multiple
  parallel lists, which made merging and overriding rules harder to reason
  about. Moving to explicit keyed permission maps gives us a single source
  of truth per host/socket entry, makes allow/deny precedence clearer, and
  gives protocol consumers access to the full rule state instead of
  derived projections only.
  
  ## Backward Compatibility
  
  ### Backward compatible
  
  - Managed requirements still accept the legacy
  `experimental_network.allowed_domains`,
  `experimental_network.denied_domains`, and
  `experimental_network.allow_unix_sockets` fields. They are normalized
  into the new canonical `domains` and `unix_sockets` maps internally.
  - App-server v2 still deserializes legacy `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` payloads, so older clients can
  continue reading managed network requirements.
  - App-server v2 responses still populate `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` as legacy compatibility views
  derived from the canonical maps.
  - `managed_allowed_domains_only` keeps the same behavior after
  normalization. Legacy managed allowlists still participate in the same
  enforcement path as canonical `domains` entries.
  
  ### Not backward compatible
  
  - Permissions profiles under `[permissions.<profile>.network]` no longer
  accept the legacy list-based keys. Those configs must use the canonical
  `[domains]` and `[unix_sockets]` tables instead of `allowed_domains`,
  `denied_domains`, or `allow_unix_sockets`.
  - Managed `experimental_network` config cannot mix canonical and legacy
  forms in the same block. For example, `domains` cannot be combined with
  `allowed_domains` or `denied_domains`, and `unix_sockets` cannot be
  combined with `allow_unix_sockets`.
  - The canonical format can express explicit `"none"` entries for unix
  sockets, but those entries do not round-trip through the legacy
  compatibility fields because the legacy fields only represent allow/deny
  lists.
  ## Testing
  `/target/debug/codex sandbox macos --log-denials /bin/zsh -c 'curl
  https://www.example.com' ` gives 200 with config
  ```
  [permissions.workspace.network.domains]
  "www.example.com" = "allow"
  ```
  and fails when set to deny: `curl: (56) CONNECT tunnel failed, response
  403`.
  
  Also tested backward compatibility path by verifying that adding the
  following to `/etc/codex/requirements.toml` works:
  ```
  [experimental_network]
  allowed_domains = ["www.example.com"]
  ```

  Celia Chen · 2026-03-27 06:17:59 +00:00
  dd30c8eedd
• Extract codex-core-skills crate (#15749)

  ## Summary
  - move skill loading and management into codex-core-skills
  - leave codex-core with the thin integration layer and shared wiring
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 12:57:42 -07:00
  9dbe098349
• Override local apps settings with requirements.toml settings (#14304)

  This PR changes app and connector enablement when `requirements.toml` is
  present locally or via remote configuration.
  
  For apps.* entries:
  - `enabled = false` in `requirements.toml` overrides the user’s local
  `config.toml` and forces the app to be disabled.
  - `enabled = true` in `requirements.toml` does not re-enable an app the
  user has disabled in config.toml.
  
  This behavior applies whether or not the user has an explicit entry for
  that app in `config.toml`. It also applies to cloud-managed policies and
  configurations when the admin sets the override through
  `requirements.toml`.
  
  Scenarios tested and verified:
  - Remote managed, user config (present) override
  - Admin-defined policies & configurations include a connector override:
    `[apps.<appID>]
  enabled = false`
  - User's config.toml has the same connector configured with `enabled =
  true`
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
    
  - Remote managed, user config (absent) override
  - Admin-defined policies & configurations include a connector override:
    `[apps.<appID>]
  enabled = false`
    - User's config.toml has no entry for the the same connector
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
    
  - Locally managed, user config (present) override
    - Local requirements.toml includes a connector override:
    `[apps.<appID>]
  enabled = false`
  - User's config.toml has the same connector configured with `enabled =
  true`
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
  
  - Locally managed, user config (absent) override
    - Local requirements.toml includes a connector override:
    `[apps.<appID>]
  enabled = false`
    - User's config.toml has no entry for the the same connector
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
  
  
  
  
  <img width="1446" height="753" alt="image"
  src="https://github.com/user-attachments/assets/61c714ca-dcca-4952-8ad2-0afc16ff3835"
  />
  <img width="595" height="233" alt="image"
  src="https://github.com/user-attachments/assets/7c8ab147-8fd7-429a-89fb-591c21c15621"
  />

  canvrno-oai · 2026-03-13 12:40:24 -07:00
  914f7c7317
• Refactor cloud requirements error and surface in JSON-RPC error (#14504)

  Refactors cloud requirements error handling to carry structured error
  metadata and surfaces that metadata through JSON-RPC config-load
  failures, including:
  * adds typed CloudRequirementsLoadErrorCode values plus optional
  statusCode
  * marks thread/start, thread/resume, and thread/fork config failures
  with structured cloud-requirements error data

  alexsong-oai · 2026-03-13 03:30:51 +00:00
  650beb177e
• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• Make cloud_requirements fail close (#13063)

  Make it fail-close only for CLI for now
  Will extend this for app-server later

  alexsong-oai · 2026-02-27 18:22:05 -08:00
  e2fef7a3d2
• chore: move config diagnostics out of codex-core (#12427)

  ## Why
  
  Compiling `codex-rs/core` is a bottleneck for local iteration, so this
  change continues the ongoing extraction of config-related functionality
  out of `codex-core` and into `codex-config`.
  
  The goal is not just to move code, but to reduce `codex-core` ownership
  and indirection so more code depends on `codex-config` directly.
  
  ## What Changed
  
  - Moved config diagnostics logic from
  `core/src/config_loader/diagnostics.rs` into
  `config/src/diagnostics.rs`.
  - Updated `codex-core` to use `codex-config` diagnostics types/functions
  directly where possible.
  - Removed the `core/src/config_loader/diagnostics.rs` shim module
  entirely; the remaining `ConfigToml`-specific calls are in
  `core/src/config_loader/mod.rs`.
  - Moved `CONFIG_TOML_FILE` into `codex-config` and updated existing
  references to use `codex_config::CONFIG_TOML_FILE` directly.
  - Added a direct `codex-config` dependency to `codex-cli` for its
  `CONFIG_TOML_FILE` use.

  Michael Bolin · 2026-02-20 23:19:29 -08:00
  1a220ad77d
• Extract codex-config from codex-core (#11389)

  `codex-core` had accumulated config loading, requirements parsing,
  constraint logic, and config-layer state handling in a single crate.
  This change extracts that subsystem into `codex-config` to reduce
  `codex-core` rebuild/test surface area and isolate future config work.
  
  ## What Changed
  
  ### Added `codex-config`
  
  - Added new workspace crate `codex-rs/config` (`codex-config`).
  - Added workspace/build wiring in:
    - `codex-rs/Cargo.toml`
    - `codex-rs/config/Cargo.toml`
    - `codex-rs/config/BUILD.bazel`
  - Updated lockfiles (`codex-rs/Cargo.lock`, `MODULE.bazel.lock`).
  - Added `codex-core` -> `codex-config` dependency in
  `codex-rs/core/Cargo.toml`.
  
  ### Moved config internals from `core` into `config`
  
  Moved modules to `codex-rs/config/src/`:
  
  - `core/src/config/constraint.rs` -> `config/src/constraint.rs`
  - `core/src/config_loader/cloud_requirements.rs` ->
  `config/src/cloud_requirements.rs`
  - `core/src/config_loader/config_requirements.rs` ->
  `config/src/config_requirements.rs`
  - `core/src/config_loader/fingerprint.rs` -> `config/src/fingerprint.rs`
  - `core/src/config_loader/merge.rs` -> `config/src/merge.rs`
  - `core/src/config_loader/overrides.rs` -> `config/src/overrides.rs`
  - `core/src/config_loader/requirements_exec_policy.rs` ->
  `config/src/requirements_exec_policy.rs`
  - `core/src/config_loader/state.rs` -> `config/src/state.rs`
  
  `codex-config` now re-exports this surface from `config/src/lib.rs` at
  the crate top level.
  
  ### Updated `core` to consume/re-export `codex-config`
  
  - `core/src/config_loader/mod.rs` now imports/re-exports config-loader
  types/functions from top-level `codex_config::*`.
  - Local moved modules were removed from `core/src/config_loader/`.
  - `core/src/config/mod.rs` now re-exports constraint types from
  `codex_config`.

  Michael Bolin · 2026-02-11 10:02:49 -08:00
  577a416f9a