501 Commits

• [codex] Calm multi-agent v2 usage prompts (#27037)

  ## Summary
  - tighten the default multi-agent v2 root and subagent usage hints to
  bias toward local work
  - add a pre-call gate to the v2 spawn_agent description for independent,
  bounded, parallelizable subtasks
  
  ## Validation
  - just fmt
  - started just test -p codex-core, but it was interrupted before
  completion per follow-up request to commit and push immediately

  jif · 2026-06-08 22:32:10 +02:00
  f9a680b907
• permissions: enforce managed permission profile allowlists (#24852)

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

  viyatb-oai · 2026-06-05 18:06:29 -07:00
  2f108f9fd9
• Make runtime workspace roots absolute in app-server API (#26552)

  Stacked on #26532.
  
  ## Why
  
  #26532 moves cwd normalization to the app-server/core boundary.
  `runtimeWorkspaceRoots` still accepted raw paths in v2 requests and in
  `ConfigOverrides`, which left core responsible for interpreting those
  roots later. This makes runtime workspace roots follow the same
  absolute-path boundary as cwd.
  
  ## What
  
  - Change v2 `runtimeWorkspaceRoots` request fields for `thread/start`,
  `thread/resume`, `thread/fork`, and `turn/start` to `AbsolutePathBuf`.
  - Deduplicate already-absolute runtime roots in app-server handlers and
  pass them through `ConfigOverrides.workspace_roots` as
  `AbsolutePathBuf`.
  - Update TUI and exec client request builders to pass absolute runtime
  roots directly.
  - Update app-server docs, schema fixtures, and focused tests for
  absolute runtime roots.
  
  ## Testing
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server runtime_workspace_roots`
  - `just test -p codex-core
  session_permission_profile_rebinds_runtime_workspace_roots`
  - `just test -p codex-tui app_server_session`
  - `just test -p codex-exec`

  pakrym-oai · 2026-06-05 11:36:53 -07:00
  76c0a5379c
• [codex] Support model-defined reasoning efforts (#26444)

  ## Summary
  - accept non-empty model-defined reasoning effort values while
  preserving built-in effort behavior
  - propagate the non-Copy effort type through core, app-server, TUI,
  telemetry, and persistence call sites
  - preserve string wire encoding and expose an open-string schema for
  clients
  - update model selection and shortcut behavior for model-advertised
  effort values
  
  ## Root cause
  `ReasoningEffort` gained a string-backed custom variant, so it could no
  longer implement `Copy` or rely on derived closed-enum serialization.
  Existing consumers still moved effort values from shared references and
  assumed a fixed built-in value set.
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.

  Ahmed Ibrahim · 2026-06-04 13:36:24 -07:00
  8ac304c299
• Route AGENTS.md loading through environment filesystems (#26205)

  ## Why
  
  Workspace-specific `AGENTS.md` loading needs to use the selected
  environment filesystem so remote workspaces and child agents read
  instructions from their actual environment instead of the host
  filesystem. The app-server should report the same instruction sources
  the initialized thread actually loaded, rather than independently
  rescanning configuration and filesystem state.
  
  ## What changed
  
  - Introduce `LoadedAgentsMd` to retain ordered user, project, and
  internal instructions with their provenance.
  - Load and canonicalize workspace `AGENTS.md` paths through the primary
  `EnvironmentManager` environment, then render the loaded instructions
  when constructing turn context.
  - Expose cached loaded instruction sources from initialized threads and
  use them for app-server start, resume, and fork responses.
  - Preserve global `CODEX_HOME` loading and separator behavior while
  excluding empty project files that did not supply model-visible
  instructions.
  - Add integration coverage for CLI injection, selected-environment
  provenance and rendering, empty environment selection, and cached
  sources on loaded-thread resume.
  
  ## Validation
  
  - `just test -p codex-core agents_md`
  - `just test -p codex-core
  selected_environment_sources_match_model_visible_instructions`
  - `just test -p codex-exec agents_md`
  - `just test -p codex-app-server instruction_sources`
  - `just test -p codex-app-server --status-level fail`

  Adam Perry @ OpenAI · 2026-06-04 12:43:07 -07:00
  e64b469bbc
• core: allow excluding tool namespaces from code mode (#26320)

  ## Why
  
  Research and training setups need to control which tool namespaces
  appear inside code mode's nested `tools` surface without disabling those
  tools entirely. This makes it possible to train against a deliberately
  reduced nested-tool setup while preserving the normal direct and
  deferred tool paths.
  
  ## What
  
  - Extend `features.code_mode` to accept structured configuration while
  preserving the existing boolean syntax.
  - Add an exact `excluded_tool_namespaces` list under
  `[features.code_mode]`:
  
    ```toml
    [features.code_mode]
    enabled = true
    excluded_tool_namespaces = ["mcp__codex_apps", "multi_agent_v1"]
    ```
  
  - Filter matching canonical `ToolName` namespaces when constructing code
  mode's nested router and code-mode-specific direct tool descriptions.
  - Keep excluded tools registered, directly exposed in mixed code mode,
  and discoverable through top-level `tool_search` when otherwise
  eligible.
  - Derive deferred nested-tool guidance after namespace filtering so the
  `exec` description does not advertise excluded-only deferred tools.
  - Preserve the boolean/table representation when materializing config
  locks and update the generated config schema.
  
  ## Testing
  
  - `just test -p codex-features`
  - `just test -p codex-config`
  - `just test -p codex-core load_config_resolves_code_mode_config`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just test -p codex-core
  excluded_deferred_namespaces_do_not_enable_nested_tool_guidance`
  - `just test -p codex-core
  code_mode_excludes_configured_nested_tool_namespaces`
  - `cargo check -p codex-thread-manager-sample`

  sayan-oai · 2026-06-04 18:40:18 +00:00
  8b1238856b
• chore: calm down (#26367)

  Prompt update to address feedback

  jif · 2026-06-04 12:46:02 +02:00
  16d02ec77c
• feat: catalog multi-agent v2 config (#26254)

  ## Why
  
  Model metadata can now select multi-agent v2 even when a user has not
  enabled `features.multi_agent_v2` in their config. Some existing configs
  still set the legacy `agents.max_threads` knob for v1 multi-agent
  behavior, so treating every v2 runtime as incompatible with
  `agents.max_threads` would break users whose only v2 signal came from
  the model catalog.
  
  The incompatible configuration is specifically enabling
  `features.multi_agent_v2` while also setting `agents.max_threads`.
  Catalog-forced v2 should use the v2 concurrency setting and ignore the
  legacy v1 cap instead of rejecting the config.
  
  ## What changed
  
  - Split config validation from runtime concurrency calculation:
  `effective_agent_max_threads` now just returns the effective cap for the
  resolved multi-agent runtime.
  - Added explicit validation for `features.multi_agent_v2` +
  `agents.max_threads` at session startup.
  - Preserved catalog-selected v2 behavior when `features.multi_agent_v2`
  is disabled, so existing configs with `agents.max_threads` keep
  starting.
  - Updated model-runtime selector coverage so a catalog v2 model still
  exposes v2 tools even when `agents.max_threads` is set and the config
  flag is disabled.
  
  ## Validation
  
  - `cargo check -p codex-core --lib`
  - `just test -p codex-core --lib -E
  "test(multi_agent_v2_feature_rejects_agents_max_threads) |
  test(catalog_v2_allows_agents_max_threads_when_feature_disabled)"`

  jif · 2026-06-04 00:24:40 +02:00
  11bceb8f8b
• core: stop threading SandboxPolicy through exec (#25700)

  ## Why
  
  #25450 attempts a broad `SandboxPolicy` removal across several unrelated
  surfaces, which makes it hard to review and still leaves new helper code
  moving legacy policies around. This PR is a narrower alternative:
  migrate only the exec-side Windows sandbox plumbing so the review can
  focus on one production path and one compatibility boundary.
  
  The goal is to stop threading `SandboxPolicy` through exec code without
  expanding the migration into app-server, protocol, telemetry, config, or
  session behavior.
  
  ## What changed
  
  - Removed `ExecRequest::compatibility_sandbox_policy()`.
  - Changed the Windows restricted-token and elevated filesystem override
  helpers to accept `PermissionProfile` plus the split filesystem/network
  policies instead of a `SandboxPolicy`.
  - Kept the remaining legacy projection local to the writable-root
  comparison that still needs to compare split policy behavior against the
  legacy Windows backend model.
  - Rejected restricted split filesystem policies that still grant
  full-disk writes before using the Windows restricted-token backend,
  preserving the previous clear-failure behavior for profiles that project
  to `ExternalSandbox`.
  - Updated the Windows sandbox override tests to exercise the new call
  shape and cover the full-write split-profile regression.
  
  ## Verification
  
  - `just test -p codex-core windows_restricted_token`
  - `just test -p codex-core windows_elevated`

  Michael Bolin · 2026-06-03 10:41:41 -07:00
  52b359b249
• feat: default hide_spawn_agent_metadata to true (#26114)

  For MAv2 CBv9

  jif · 2026-06-03 12:22:23 +02:00
  668703c23f
• config: express implicit sandbox defaults as permission profiles (#25926)

  ## Why
  
  `PermissionProfile` is becoming the default way to represent Codex
  permissions, but the implicit default behavior should stay the same for
  now:
  
  - trusted projects use `:workspace`
  - untrusted projects also use `:workspace`
  - roots without a trust decision use `:read-only`
  - unsandboxed Windows falls back to `:read-only`
  
  This keeps the existing sandbox semantics while making silent config
  defaults observable as built-in permission profiles instead of treating
  the legacy `SandboxPolicy` projection as the primary shape.
  
  ## What Changed
  
  - Refactored legacy sandbox derivation to resolve the configured sandbox
  mode once, then apply the implicit project fallback only when no sandbox
  mode was configured.
  - Preserved the existing trust-decision fallback: trusted and untrusted
  projects default to workspace-write where supported.
  - Added empty-config coverage asserting that an untrusted project
  resolves to the built-in active permission profile (`:workspace` outside
  unsandboxed Windows).
  
  ## Verification
  
  - `just fmt`
  - `just test -p codex-core 'config::'`
  - `just test -p codex-config`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25926).
  * __->__ #25926

  Michael Bolin · 2026-06-02 16:26:36 -07:00
  a28b32a835
• config: remove dead profile sandbox fallback (#25943)

  ## Why
  
  `profile_sandbox_mode` was left over from the old selected legacy
  profile path. Production now always derives permissions without that
  value, and legacy profile contents are ignored, so keeping a parameter
  that is always `None` makes `derive_permission_profile` look like it
  still supports a fallback that no longer exists.
  
  ## What Changed
  
  - Removed the `profile_sandbox_mode` argument from
  `ConfigToml::derive_permission_profile`.
  - Updated the production caller and legacy sandbox-policy test helper to
  match.
  - Dropped the stale unselected legacy-profile sandbox test that only
  protected the removed fallback shape.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-core 'config::'`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25943).
  * #25926
  * __->__ #25943

  Michael Bolin · 2026-06-02 22:05:04 +00:00
  c6d76750e8
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• core: derive built-in permission profiles from raw policies (#25739)

  ## Why
  
  Permission profiles that extend a built-in profile should behave like
  other TOML inheritance: parent entries provide defaults, and child keys
  override matching fields before the profile is compiled.
  
  That was not true for `:workspace`. Previously, a profile with `extends
  = ":workspace"` seeded the compiled runtime
  `PermissionProfile::workspace_write()` policy and then appended child
  filesystem entries. A child override such as `":tmpdir" = "read"`
  therefore left the inherited `":tmpdir" = "write"` entry in the final
  policy. Since same-target `write` wins over `read` during runtime
  resolution, the child override was ineffective.
  
  This also needs a clear source of truth for the built-in profiles. The
  protocol-level sandbox policy constructors now define the raw built-in
  filesystem entries, and both `PermissionProfile` presets and
  config-profile inheritance derive from those same values.
  
  ## What Changed
  
  - Add a canonical `FileSystemSandboxPolicy::read_only()` constructor
  while keeping the read-only and workspace-write raw filesystem entries
  explicit and independent.
  - Derive `PermissionProfile::read_only()` from
  `FileSystemSandboxPolicy::read_only()`;
  `PermissionProfile::workspace_write()` continues to derive from
  `FileSystemSandboxPolicy::workspace_write()`.
  - Build extensible `:read-only` and `:workspace` parent profiles by
  projecting those canonical sandbox policies into
  `PermissionProfileToml`, then merge user overrides at the TOML layer
  before compilation.
  - Add config parsing support for `:slash_tmp` so the built-in
  `:workspace` parent can be expressed in the same TOML-shaped filesystem
  table as user profiles.
  - Document that `PermissionsToml::resolve_profile()` returns an
  already-merged `PermissionProfileToml`, and return that profile directly
  after removing the resolved-profile wrapper.
  - Extend the config test for `extends = ":workspace"` to assert that
  inherited `":slash_tmp" = "write"` is preserved and that a child
  `":tmpdir" = "read"` entry replaces the inherited `write` entry.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-protocol`
  - `just test -p codex-core
  permissions_profiles_resolve_extends_parent_first_with_child_overrides`
  - `just test -p codex-core
  default_permissions_profile_can_extend_builtin_workspace`
  - `just test -p codex-core`
    - Result: 2596 passed, 4 failed, 1 timed out.
  - The failures were existing sandbox/environment-sensitive tests
  unrelated to this permissions change:
  
  `suite::user_shell_cmd::user_shell_command_does_not_set_network_sandbox_env_var`,
  
  `suite::user_shell_cmd::user_shell_command_history_is_persisted_and_shared_with_model`,
  
  `suite::abort_tasks::interrupt_persists_turn_aborted_marker_in_next_request`,
      `suite::abort_tasks::interrupt_tool_records_history_entries`, and
  
  `thread_manager::tests::start_thread_uses_all_default_environments_from_codex_home`.

  Michael Bolin · 2026-06-02 10:57:35 -07:00
  593df8773d
• Resolve per-thread multi-agent runtime (#25722)

  Stack split from #25708. Original PR intentionally left open. This third
  PR resolves the effective per-thread multi-agent runtime from persisted
  metadata, inherited runtime, and current model selection.

  jif-oai · 2026-06-02 14:31:00 +02:00
  bf9fd885b2
• [codex] Rename multi-agent v2 assign_task to followup_task (#25636)

  ## Summary
  
  Renames the MultiAgentV2 turn-triggering tool from `assign_task` to
  `followup_task` so the exposed tool name better describes sending an
  additional task to an existing agent.
  
  This updates the tool spec, handler/module names, registry wiring,
  default multi-agent v2 usage hints, and tests. Rollout trace
  classification keeps accepting legacy `assign_task` events so older
  traces still reduce correctly, while docs show the new tool name.
  
  ## Test plan
  
  - `just test -p codex-core followup_task`
  - `just test -p codex-core -E
  'test(multi_agent_feature_selects_one_agent_tool_family) |
  test(multi_agent_v2_can_use_configured_tool_namespace) |
  test(code_mode_only_can_expose_namespaced_multi_agent_v2_as_normal_tools)'`
  - `just test -p codex-rollout-trace`
  - `just fix -p codex-core`
  - `just fix -p codex-rollout-trace`
  
  Notes: `just fmt` ran `cargo fmt` but failed in the Python ruff phase
  because the local environment could not resolve `hatchling>=1.27.0` from
  the configured internal registry. A full `just test -p codex-core` also
  hit unrelated environment-sensitive integration failures involving
  missing spawned test binaries/sandbox behavior; the changed multi-agent
  spec/handler tests passed in the filtered runs above.

  jif-oai · 2026-06-01 19:57:11 +02:00
  6ddb747e76
• Set multi-agent v2 dogfood defaults (#25266)

  ## Summary
  - default multi-agent v2 to direct-model-only tools so code mode does
  not wrap subagent tools
  - add default root/subagent team prompts aligned with dogfood training
  assumptions
  - tighten spawn-agent model override wording to prefer the inherited
  model by default
  
  ## Tests
  - just fmt
  - just test -p codex-core
  spawn_agent_description_lists_visible_models_and_reasoning_efforts
  - just test -p codex-core
  multi_agent_v2_default_session_thread_cap_counts_root
  - just test -p codex-rollout-trace
  - just fix -p codex-core
  - just fix -p codex-rollout-trace
  
  Note: a broad just test -p codex-core run was attempted locally, but
  this sandbox produced unrelated environment failures around
  sandbox-exec, missing test_stdio_server, and realtime timeouts.

  jif-oai · 2026-06-01 10:24:46 +02:00
  8d49394feb
• feat(config) experimental_request_user_input toggle (#24541)

  ## Summary
  Experimental flag to allow toggling `request_user_input`:
  
  ```
  tools.experimental_request_user_input = false
  ```
  
  ## Testing
  - [x] Added unit tests

  Dylan Hurd · 2026-05-29 21:35:53 -07:00
  e0435afb72
• 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
• Move config document helpers into their own module (#25110)

  ## Why
  
  `core/src/config/edit.rs` owns the config edit state machine, but it
  also carried the TOML document helper code inline as a nested module.
  Moving those helpers into their own file keeps the edit orchestration
  easier to scan without changing the config persistence behavior.
  
  ## What changed
  
  - Moved the existing `document_helpers` module from
  `core/src/config/edit.rs` into
  `core/src/config/edit/document_helpers.rs`.
  - Added `mod document_helpers;` so the existing `pub(super)` helper API
  remains available to the rest of `config::edit`.
  
  ## Testing
  
  Not run; this is a refactor-only module extraction with no intended
  behavior change.

  jif-oai · 2026-05-29 18:49:21 +02:00
  f4e9d2caac
• fix(config): use deny for Unix socket permissions (#24970)

  ## Why
  
  Unix socket permissions still accepted and displayed `"none"` while file
  permissions use the clearer `"deny"` spelling. This keeps network Unix
  socket policy vocabulary consistent with filesystem policy vocabulary.
  
  ## What changed
  
  - Replace the Unix socket permission variant and serialized spelling
  from `none` to `deny` across config, feature configuration, and network
  proxy types.
  - Update app-server v2 serialization, TUI debug output, focused tests,
  and generated schemas to expose `"deny"`.
  - Add coverage for denied Unix socket entries in managed requirements
  and profile overlay behavior.
  
  ## Security
  
  This is a vocabulary change for explicit Unix socket rejection, not a
  network access expansion. Denied entries continue to be omitted from the
  effective allowlist.
  
  ## Validation
  
  - `just fmt`
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just test -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-tui -E
  'test(network_requirements_are_preserved_as_constraints_with_source) |
  test(network_permission_containers_project_allowed_and_denied_entries) |
  test(network_toml_overlays_unix_socket_permissions_by_path) |
  test(permissions_profiles_resolve_extends_parent_first_with_child_overrides)
  | test(network_requirements_serializes_canonical_and_legacy_fields) |
  test(debug_config_output_formats_unix_socket_permissions)'`\n- Automatic
  `bench-smoke` follow-up from `just test`\n- `cargo clippy -p
  codex-config -p codex-core -p codex-features -p codex-network-proxy -p
  codex-app-server-protocol -p codex-app-server -p codex-tui --all-targets
  -- -D warnings`

  viyatb-oai · 2026-05-28 23:53:26 +00:00
  bf72be5927
• Move memories root setup out of core config (#24758)

  ## Why
  
  Config loading should not create or write-authorize the memories root
  just because memory support exists. Memory startup is the code path that
  actually materializes that tree.
  
  ## What
  
  - Stop creating the memories root during Config load and remove it from
  legacy workspace-write projections.
  - Grant the memories root read access only when the memories feature and
  use_memories are enabled.
  - Create the memories root inside memories startup before seeding
  extension instructions.
  - Update config and startup tests around the ownership boundary.
  
  ## Tests
  
  - just fmt
  - just fix -p codex-core
  - just fix -p codex-memories-write
  - just test -p codex-core
  memory_tool_makes_memories_root_readable_without_creating_or_widening_writes
  workspace_write_includes_configured_writable_root_once_without_memories_root
  permission_profile_override_keeps_memories_root_out_of_legacy_projection
  permissions_profiles_allow_direct_write_roots_outside_workspace_root
  default_permissions_profile_populates_runtime_sandbox_policy
  - just test -p codex-memories-write memories_startup_creates_memory_root
  
  Note: a broader just test -p codex-core run is not clean in this
  sandbox; it hit missing test_stdio_server plus seatbelt, realtime, and
  environment-sensitive failures. The changed config tests above pass.

  jif-oai · 2026-05-28 11:51:24 +02:00
  d5ec93f379
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• tui: add named permission profile picker (#21559)

  ## Why
  
  Users who opt into named permission profiles through
  `default_permissions` or `[permissions.*]` should stay in named-profile
  semantics when they open `/permissions`. The legacy picker rewrites
  those users into anonymous preset state, which loses the active profile
  identity and hides custom configured profiles.
  
  ## What changed
  
  - Switch `/permissions` to a profile-aware picker when profile mode is
  active.
  - Show friendly built-in labels instead of raw `:` profile syntax.
  - Include configured custom profiles and their descriptions in the
  picker.
  - Route selections through the split TUI profile-selection flow below
  this PR.
  - Add TUI snapshots and regression coverage for built-ins, custom
  profiles, and conflicting legacy runtime overrides.
  
  ## Stack
  
  1. [#22931](https://github.com/openai/codex/pull/22931):
  runtime/session/network propagation for active permission profiles.
  2. [#23708](https://github.com/openai/codex/pull/23708): TUI selection
  plumbing and guardrail flow.
  3. **This PR**: profile-aware `/permissions` menu and custom profile
  display.
  
  ## UX impact
  
  In profile mode, `/permissions` shows the same human-facing built-ins
  users already know:
  
  ```text
  Default
  Auto-review
  Full Access
  Read Only
  locked-down
  web-enabled
  ```
  
  Selecting `locked-down` keeps `active_permission_profile =
  Some("locked-down")`; selecting a built-in keeps the friendly label
  while switching to its named built-in profile.
  
  ## Screenshots
  
  Live `$test-tui` smoke screenshots uploaded through GitHub attachments:
  
  **Profile mode with built-ins and custom profiles**
  
  <img width="832" alt="Profile mode permissions picker with custom
  profiles"
  src="https://github.com/user-attachments/assets/58b72431-418c-4839-9e39-575076db4c8f"
  />
  
  **Legacy mode remains anonymous preset picker**
  
  <img width="1232" alt="Legacy permissions picker"
  src="https://github.com/user-attachments/assets/95f413ab-4cee-411c-9afb-92580a885c97"
  />
  
  <img width="1296" height="906" alt="image"
  src="https://github.com/user-attachments/assets/ea381a78-9904-4aa2-828f-b7f2e43f60f2"
  />
  
  <img width="705" height="207" alt="Screenshot 2026-05-18 at 2 58 00 PM"
  src="https://github.com/user-attachments/assets/2fa6dd71-0296-449e-a6de-a72d78a1cb70"
  />
  
  ## Validation
  
  - `git diff --cached --check` before commit.
  - Full test run skipped at the user request while pushing the split
  stack.

  viyatb-oai · 2026-05-26 16:39:55 +00:00
  f6fd753039
• feat: gate dedicated memories tools in config (#24600)

  ## Why
  
  The memories extension already has dedicated `list`, `read`, `search`,
  and `add_ad_hoc_note` tools, but app-server registration was still
  disabled. The memories app collaborator needs an explicit config switch
  so those native extension tools can be exposed intentionally, without
  making ordinary memory prompt usage automatically register the dedicated
  tool surface.
  
  ## What changed
  
  - Added `[memories].dedicated_tools`, defaulting to `false`, to
  `MemoriesToml` / `MemoriesConfig`.
  - Regenerated `core/config.schema.json` for the new setting.
  - Registered the memories extension as a `ToolContributor`, while
  keeping tool contribution gated on both memories being enabled and
  `dedicated_tools = true`.
  - Added tests for the disabled default, the enabled dedicated-tools
  path, and installer registration.
  
  ## Verification
  
  - `just test -p codex-config -p codex-memories-extension`

  jif-oai · 2026-05-26 18:18:58 +02:00
  ef6528c6c7
• Move MCP tool naming mode into manager (#21576)

  ## Why
  
  The `non_prefixed_mcp_tool_names` feature should be applied where MCP
  tools become model-visible, not by remapping names later in core.
  Keeping the decision in `McpConnectionManager` construction makes
  `ToolInfo` the single shaped view that spec building, deferred tool
  search, routing, and unavailable-tool placeholders can consume directly.
  
  This also preserves the existing external behavior while the feature is
  off, and keeps the feature-on behavior for code mode and hooks explicit
  at the manager boundary.
  
  ## What Changed
  
  - Add `McpToolNameMode` to `codex-mcp` and flow it through `McpConfig`
  into `McpConnectionManager::new`.
  - Normalize MCP `ToolInfo` names in the manager using either
  legacy-prefixed namespaces or non-prefixed namespaces; the legacy path
  adds `mcp__` without restoring the old trailing namespace suffix.
  - Remove the core-side MCP name remapping path so specs, tool search,
  session resolution, and unavailable-tool placeholder construction use
  the manager-provided `ToolName` values directly.
  - Keep code mode flattening on the `__` namespace separator.
  - Preserve hook compatibility by giving non-prefixed MCP hook names
  legacy `mcp__...` matcher aliases.
  - Add/adjust integration and unit coverage for non-prefixed code-mode
  behavior, hook matching with the feature on and off, and manager-level
  legacy prefixing.
  
  ## Testing
  
  - `cargo test -p codex-mcp --lib`
  - `cargo test -p codex-core --lib tools::spec::tests -- --nocapture`
  - `cargo test -p codex-core --lib mcp_tools -- --nocapture`
  - `cargo test -p codex-core --lib mcp_tool_exposure -- --nocapture`
  - `cargo test -p codex-core --test all mcp_tool -- --nocapture`
  - `cargo test -p codex-core --test all search_tool -- --nocapture`
  - `cargo test -p codex-core --test all hooks_mcp -- --nocapture`
  - `cargo test -p codex-core --test all
  code_mode_uses_non_prefixed_mcp_tool_names_when_feature_enabled --
  --nocapture`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-features`

  pakrym-oai · 2026-05-26 08:21:15 -07:00
  ff7513cd83
• chore: stop consuming legacy config profiles (#24076)

  ## Why
  
  The old config-profile mechanism should no longer influence runtime
  behavior now that profile selection has moved to file-based `--profile`
  config files. Core already rejects a selected legacy `profile = "..."`
  with a migration error in
  [`core/src/config/mod.rs`](https://github.com/openai/codex/blob/d6451fcb79edc4a71bc9e811bcda06fd3c36562e/codex-rs/core/src/config/mod.rs#L2521-L2529),
  but a few residual consumers still read legacy `[profiles.*]` data while
  performing managed-feature checks and personality migration.
  
  That kept dead legacy profile state relevant after selection had been
  removed, and could make personality migration depend on a stale or
  missing old profile.
  
  ## What changed
  
  - Stop scanning legacy `[profiles.*]` feature settings when validating
  managed feature requirements.
  - Make personality migration consider only top-level `personality` and
  `model_provider` settings.
  - Remove the now-unused `ConfigToml::get_config_profile` helper.
  - Update personality migration coverage to verify that legacy profile
  personality fields and missing legacy profile names no longer affect
  that migration path.
  
  This keeps the legacy `profile` / `profiles` config shape available for
  the remaining compatibility and migration diagnostics; it only removes
  these behavior consumers.
  
  ## Verification
  
  - Updated `core/tests/suite/personality_migration.rs` for the new
  legacy-profile behavior.
  - Focused test command: `cargo test -p codex-core
  personality_migration`.

  jif-oai · 2026-05-26 10:34:43 +02:00
  4f7d6b4ef7
• package: include zsh fork in Codex package (#23756)

  ## Why
  
  The package layout gives Codex a stable place for runtime helpers that
  should travel with the entrypoint. `shell_zsh_fork` still required users
  to configure `zsh_path` manually, even though we already publish
  prebuilt zsh fork artifacts.
  
  This PR builds on #24129 and uses the shared DotSlash artifact fetcher
  to include the zsh fork in Codex packages when a matching target
  artifact exists. Packaged Codex builds can then discover the bundled
  fork automatically; the user/profile `zsh_path` override is removed so
  the feature uses the package-managed artifact instead of a legacy path
  knob.
  
  ## What Changed
  
  - Added `scripts/codex_package/codex-zsh`, a checked-in DotSlash
  manifest for the current macOS arm64 and Linux zsh fork artifacts.
  - Taught `scripts/build_codex_package.py` to fetch the matching zsh fork
  artifact and install it at `codex-resources/zsh/bin/zsh` when available
  for the selected target.
  - Added package layout validation for the optional bundled zsh resource.
  - Added `InstallContext::bundled_zsh_path()` and
  `InstallContext::bundled_zsh_bin_dir()` for package-layout resource
  discovery.
  - Threaded the packaged zsh path through config loading as the runtime
  `zsh_path` for packaged installs, and removed the config/profile/CLI
  override path.
  - Kept the packaged default zsh override typed as `AbsolutePathBuf`
  until the existing runtime `Config::zsh_path` boundary.
  - Updated app-server zsh-fork integration tests to spawn
  `codex-app-server` from a temporary package layout with
  `codex-resources/zsh/bin/zsh`, matching the new packaged discovery path
  instead of setting `zsh_path` in config.
  - Switched package executable copying from metadata-preserving `copy2()`
  to `copyfile()` plus explicit executable bits, which avoids macOS
  file-flag failures when local smoke tests use system binaries as inputs.
  
  ## Testing
  
  To verify that the `zsh` executable from the Codex package is picked up
  correctly, first I ran:
  
  ```shell
  ./scripts/build_codex_package.py
  ```
  
  which created:
  
  ```
  /private/var/folders/vw/x2knqmks50sfhfpy27nftl900000gp/T/codex-package-pms94kdp/
  ```
  
  so then I ran:
  
  ```
  /private/var/folders/vw/x2knqmks50sfhfpy27nftl900000gp/T/codex-package-pms94kdp/bin/codex exec --enable shell_zsh_fork 'run `echo $0`'
  ```
  
  which reported the following, as expected:
  
  ```
  /private/var/folders/vw/x2knqmks50sfhfpy27nftl900000gp/T/codex-package-pms94kdp/codex-resources/zsh/bin/zsh
  ```
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23756).
  * #23768
  * __->__ #23756

  Michael Bolin · 2026-05-22 17:54:07 -07:00
  c7bcb90f9b
• Add new enterprise requirement gate (#23736)

  Add new enterprise requirement gate.
  
  Validation:
  - `cargo test -p codex-config --lib`
  - `cargo test -p codex-app-server-protocol --lib`
  - `cargo test -p codex-tui --lib debug_config`
  - `cargo test -p codex-app-server --lib` *(fails: stack overflow in
  `in_process::tests::in_process_start_initializes_and_handles_typed_v2_request`;
  reproduces when run alone)*

  adams-oai · 2026-05-22 11:33:44 -07:00
  865ca936db
• config: remove legacy profile write paths (#24055)

  ## Why
  
  [#23883](https://github.com/openai/codex/pull/23883) moved the
  user-facing `--profile` flag onto profile v2 and
  [#23886](https://github.com/openai/codex/pull/23886) removed CLI
  forwarding for the legacy profile-v1 path. Core and TUI config
  persistence still carried `active_profile` and
  `ConfigEditsBuilder::with_profile`, which let later writes continue
  targeting legacy `[profiles.<name>]` tables after profile selection
  moved to profile-v2 config files.
  
  ## What
  
  - Remove legacy profile routing from
  [`ConfigEditsBuilder`](https://github.com/openai/codex/blob/4b38e9c22e762261d7f7eef49d8a21792e241a06/codex-rs/core/src/config/edit.rs#L1064-L1294),
  so core config edits no longer carry `with_profile` or infer
  `[profiles.*]` write targets from a `profile` key.
  - Drop `active_profile` plumbing from runtime `Config`, TUI
  startup/state, app-server config override forwarding, and Windows
  sandbox setup persistence.
  - Make app-server-backed TUI config edits use unscoped model,
  service-tier, feature, Auto-review, plan-mode, and Windows sandbox paths
  through
  [`tui/src/config_update.rs`](https://github.com/openai/codex/blob/4b38e9c22e762261d7f7eef49d8a21792e241a06/codex-rs/tui/src/config_update.rs#L43-L112).
  - Update config edit coverage so legacy `profile` state stays untouched
  by direct model writes, and remove tests whose only contract was the
  deleted profile-scoped persistence path.
  
  ## Testing
  
  - Not run locally.

  jif-oai · 2026-05-22 12:50:42 +02:00
  2c6605ab35
• config: remove legacy profile v1 resolution (#24051)

  ## Why
  
  [#23883](https://github.com/openai/codex/pull/23883) moved user-facing
  `--profile` selection onto profile v2, and
  [#23886](https://github.com/openai/codex/pull/23886) removed the old CLI
  `config_profile` override path. Core still had a second legacy path:
  `profile = "..."` could select `[profiles.*]` values while runtime
  config was built. Keeping that resolver alive preserves the old
  precedence model and profile-carrying surfaces even though profile
  selection now points at `$CODEX_HOME/<name>.config.toml`.
  
  ## What
  
  - Reject legacy top-level `profile = "..."` config while loading runtime
  config, with an error that points callers at `--profile <name>` and
  `<name>.config.toml` in the [core load
  path](https://github.com/openai/codex/blob/3d923366eca10a29143623124c6c6e538f058269/codex-rs/core/src/config/mod.rs#L2524-L2531).
  - Remove the remaining profile-v1 merge points from runtime config
  resolution, including features, permissions, model/provider selection,
  web search, Windows sandbox settings, TUI settings, role reloads, and
  OSS provider lookup.
  - Drop the leftover profile override surface from
  [`ConfigOverrides`](https://github.com/openai/codex/blob/3d923366eca10a29143623124c6c6e538f058269/codex-rs/core/src/config/mod.rs#L2118-L2148)
  and from the MCP server `codex` tool schema.
  - Prune profile-precedence tests that only exercised the removed
  resolver and replace them with rejection coverage for the legacy
  selector.
  
  ## Testing
  
  - Not run in this metadata pass.
  - Added
  [`legacy_profile_selection_is_rejected`](https://github.com/openai/codex/blob/3d923366eca10a29143623124c6c6e538f058269/codex-rs/core/src/config/config_tests.rs#L7942-L7965)
  coverage for the new runtime guard.

  jif-oai · 2026-05-22 12:13:52 +02:00
  fd72e99384
• Remove plugin hooks feature flag (#22552)

  # Why
  
  This is a follow-up stacked on top of the `plugin_hooks` default-on
  change. Once we are comfortable making plugin hooks part of the normal
  plugin behavior, the separate feature flag stops buying us much and
  leaves extra branching/cache state behind.
  
  # What
  
  - remove the `PluginHooks` feature and generated config-schema entries
  - make plugin hook loading/listing follow plugin enablement directly
  - drop plugin-manager cache/state that only existed to distinguish
  hook-flag toggles
  - remove tests and fixtures that modeled `plugin_hooks = true/false`

  Abhinav · 2026-05-21 19:15:18 +00:00
  24faf49b2a
• 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
• feat: support managed permission profiles in requirements.toml (#23433)

  ## Why
  
  Cloud-managed `requirements.toml` should be able to define the managed
  permission profiles a client may select and constrain that selectable
  set without requiring local user config to recreate the profile catalog.
  
  This keeps requirements focused on restrictions. The selected default
  remains a config or session choice, while requirements contribute the
  managed profile bodies and `allowed_permissions` allowlist that the
  config-loading boundary validates before a resolved runtime
  `PermissionProfile` is installed.
  
  ## What changed
  
  - Add `requirements.toml` support for a managed permission-profile
  catalog plus its allowlist:
  
  ```toml
  allowed_permissions = ["review", "build"]
  
  [permissions.review]
  extends = ":read-only"
  
  [permissions.build]
  extends = ":workspace"
  ```
  
  - Merge requirements-defined profile bodies into the effective
  permission catalog and reject profile ids that collide with
  config-defined profiles.
  - Validate that every `allowed_permissions` entry resolves to a built-in
  or catalog profile before selection uses it.
  - Preserve allowed configured named-profile selections. When a
  configured named profile is disallowed, fall back to the first allowed
  requirements profile with a startup warning.
  - Keep built-in selections and the stock trust-based `:read-only` /
  `:workspace` fallback path intact when no permission profile is
  explicitly selected.
  - Centralize the managed catalog and allowlist selection path in
  `EffectivePermissionSelection` so the requirements boundary is visible
  in config loading.
  - Surface `allowedPermissions` through `configRequirements/read`, and
  update the generated app-server schema fixtures plus the app-server
  README.
  
  ## Validation
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core system_requirements_`
  - `cargo test -p codex-core system_allowed_permissions_`
  - `cargo test -p codex-app-server-protocol`
  - `just write-app-server-schema`
  
  ## Related work
  
  - Uses merged permission-profile inheritance support from #22270 and
  #23705.
  - Kept separate from the in-flight permission profile listing API in
  #23412.

  viyatb-oai · 2026-05-20 17:33:01 -07:00
  713a5b1b00
• [codex] Reject read-only fallback with approvals disabled (#23774)

  ## Why
  
  If a user configures `approval_policy = "never"` with `sandbox_mode =
  "danger-full-access"`, managed requirements can reject full access and
  force the existing permission fallback to read-only. That leaves Codex
  in a dead-end session: writes are blocked by the sandbox, while
  approvals are disabled so the session cannot ask to proceed.
  
  This PR rejects that constrained configuration during startup instead of
  letting the TUI enter a read-only session that cannot make progress. The
  rejection is attached to the requirement-constrained permission path in
  [`Config`](https://github.com/openai/codex/blob/39f0abc0a7c0ed0e348a6843e9f0c7b76e2400bc/codex-rs/core/src/config/mod.rs#L3301-L3318).
  
  ## What changed
  
  - Reject the `danger-full-access` to read-only managed-requirements
  fallback when the effective approval policy is `never`.
  - Explain in the startup config error why the fallback is invalid and
  how to fix it.
  - Add a regression test for the managed requirements path.

  viyatb-oai · 2026-05-20 17:17:59 -07:00
  a27d3847b5
• Use named MITM permissions config (#18240)

  ## Stack
  1. Parent PR: #18868 adds MITM hook config and model only.
  2. Parent PR: #20659 wires hook enforcement into the proxy request path.
  3. This PR changes the user facing PermissionProfile TOML shape.
  
  ## Why
  1. The broader goal is to make MITM clamping usable from the same
  permission profile that already controls network behavior.
  2. This PR is the config UX layer for the stack. It moves MITM policy
  into `[permissions.<profile>.network.mitm]` instead of exposing the flat
  runtime shape to users.
  3. The named hook and action tables belong here because users need
  reusable policy blocks that are easy to review, while the proxy runtime
  only needs a flat hook list.
  4. This PR validates action refs during config parsing so mistakes in
  the user facing policy fail before a proxy session starts.
  5. Keeping the lowering here lets the proxy keep its simpler runtime
  model and lets PermissionProfile remain the single source of network
  permission policy.
  
  ## Summary
  1. Keep MITM policy inside `[permissions.<profile>.network.mitm]` so the
  selected PermissionProfile owns network proxy policy.
  2. Use named MITM hooks under
  `[permissions.<profile>.network.mitm.hooks.<name>]`.
  3. Put host, methods, path prefixes, query, headers, body, and action
  refs on the hook table.
  4. Define reusable action blocks under
  `[permissions.<profile>.network.mitm.actions.<name>]`.
  5. Represent action blocks with `NetworkMitmActionToml`, then lower them
  into the proxy runtime action config.
  6. Reject unknown refs, empty refs, and empty action blocks during
  config parsing.
  7. Keep the runtime hook model unchanged by lowering config into the
  existing proxy hook list.
  8. Preserve the #20659 activation fix for nested MITM policy.
  
  ## Example
  ```toml
  [permissions.workspace.network.mitm]
  enabled = true
  
  [permissions.workspace.network.mitm.hooks.github_write]
  host = "api.github.com"
  methods = ["POST", "PUT"]
  path_prefixes = ["/repos/openai/"]
  action = ["strip_auth"]
  
  [permissions.workspace.network.mitm.actions.strip_auth]
  strip_request_headers = ["authorization"]
  ```
  
  ## Validation
  1. Regenerated the config schema.
  2. Ran the core MITM config parsing and validation tests.
  3. Ran the core PermissionProfile MITM proxy activation tests.
  4. Ran the core config schema fixture test.
  5. Ran the network proxy MITM policy tests.
  6. Ran the scoped Clippy fixer for the network proxy crate.
  7. Ran the scoped Clippy fixer for the core crate.
  
  ---------
  
  Co-authored-by: Winston Howes <winston@openai.com>

  evawong-oai · 2026-05-20 17:10:37 -07:00
  3cae84009a
• Honor client-resolved service tier defaults (#23537)

  ## Why
  
  Model catalog responses can now advertise a nullable
  `default_service_tier` for each model. Codex needs to preserve three
  distinct states all the way from config/app-server inputs to inference:
  
  - no explicit service tier, so the client may apply the current model
  catalog default when FastMode is enabled
  - explicit `default`, meaning the user intentionally wants standard
  routing
  - explicit catalog tier ids such as `priority`, `flex`, or future tiers
  
  Keeping those states distinct prevents the UI from showing one tier
  while core sends another, especially after model switches or app-server
  `thread/start` / `turn/start` updates.
  
  ## What Changed
  
  - Plumbed `default_service_tier` through model catalog protocol types,
  app-server model responses, generated schemas, model cache fixtures, and
  provider/model-manager conversions.
  - Added the request-only `default` service tier sentinel and normalized
  legacy config spelling so `fast` in `config.toml` still materializes as
  the runtime/request id `priority`.
  - Moved catalog default resolution to the TUI/client side, including
  recomputing the effective service tier when model/FastMode-dependent
  surfaces change.
  - Updated app-server thread lifecycle config construction so
  `serviceTier: null` preserves explicit standard-routing intent by
  mapping to `default` instead of internal `None`.
  - Kept core responsible for validating explicit tiers against the
  current model and stripping `default` before `/v1/responses`, without
  applying catalog defaults itself.
  
  ## Validation
  
  - `CARGO_INCREMENTAL=0 cargo build -p codex-cli`
  - `CARGO_INCREMENTAL=0 cargo test -p codex-app-server model_list`
  - `cargo test -p codex-tui service_tier`
  - `cargo test -p codex-protocol service_tier_for_request`
  - `cargo test -p codex-core get_service_tier`
  - `RUST_MIN_STACK=8388608 CARGO_INCREMENTAL=0 cargo test -p codex-core
  service_tier`

  Shijie Rao · 2026-05-20 15:57:50 -07:00
  370b13afc9
• core: refresh active permission profiles at runtime (#22931)

  ## Why
  
  Once a named permission profile is selected, runtime state has to keep
  that profile identity intact instead of collapsing back to anonymous
  effective permissions. The session refresh path also needs to rebuild
  profile-derived network proxy state so active profile switches take
  effect consistently.
  
  ## What changed
  
  - Preserve the active permission profile through session updates.
  - Rebuild profile-derived runtime/network configuration when the active
  profile changes.
  - Keep the runtime path aligned with the current session configuration
  APIs.
  - Tighten the affected tests, including the Windows delete-pending
  memory-file case that was intermittently tripping CI.
  
  ## Stack
  
  1. **This PR**: runtime/session/network propagation for active
  permission profiles.
  2. [#23708](https://github.com/openai/codex/pull/23708): TUI selection
  plumbing and guardrail flow.
  3. [#21559](https://github.com/openai/codex/pull/21559): profile-aware
  `/permissions` menu and custom profile display.
  
  <img width="1296" height="906" alt="image"
  src="https://github.com/user-attachments/assets/077fa3a7-80cb-4925-80b1-d2395018d90a"
  />

  viyatb-oai · 2026-05-20 21:55:21 +00:00
  40ad7be2b5
• feat(permissions): resolve permission profile inheritance (#22270)

  ## Stack
  
  This is the foundation PR for the permission-profile inheritance stack.
  
  - This PR adds config-level `extends` resolution and merge semantics.
  - Follow-up: #23705 applies resolved profiles at runtime and updates the
  active-profile protocol surfaces.
  
  ## Why
  
  Permission profiles are starting to carry enough policy that
  copy-pasting near-identical definitions becomes hard to review and easy
  to drift. Before the runtime can consume inherited profiles, the config
  layer needs one explicit resolver that can merge parent chains and
  reject unsafe or invalid inheritance shapes.
  
  ## What changed
  
  - Add `extends` to permission-profile TOML and resolve parent chains in
  inheritance order.
  - Merge inherited profile TOML with the existing config merge behavior
  while preserving the permission-specific normalization needed for
  network domain keys.
  - Keep parent descriptions out of resolved child profiles and record
  inherited profile names separately for downstream consumers.
  - Reject undefined parents, unsupported built-in parents, and
  inheritance cycles with targeted errors.
  - Cover resolver behavior with TOML fixture tests and refresh the
  generated config schema.
  
  ## Validation
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core permissions_profiles_`

  viyatb-oai · 2026-05-20 20:12:07 +00:00
  fe7c069fe6
• Add MITM hook config model (#18868)

  ## Stack
  1. This PR adds MITM hook config and model only.
  2. Runtime follow up: #20659 wires hook enforcement into the proxy
  request path.
  3. User facing config follow up: #18240 moves MITM policy into the
  PermissionProfile network tree.
  
  ## Why
  1. Viyat asked for the original parent PR to be split so reviewers can
  inspect the policy model before request behavior changes.
  2. This PR gives the proxy a typed MITM hook model, validation, matcher
  compilation, permissions TOML plumbing, schema support, and config
  tests.
  3. This PR deliberately does not change CONNECT or MITM request
  handling.
  4. Keeping runtime behavior out of this PR makes the review boundary
  simple: does the policy model parse, validate, compile, and lower
  correctly.
  
  ## Summary
  1. Add the MITM hook config model and matcher compilation.
  2. Validate hosts, methods, paths, query matchers, header matchers,
  secret sources, and reserved body matching.
  3. Add wildcard matcher support for path, query value, and header value
  matching.
  4. Add permissions TOML and schema support for flat runtime hook config.
  5. Add config loader tests for MITM hook overlay behavior.
  
  ## Validation
  1. Regenerated the config schema.
  2. Ran the network proxy MITM hook unit tests.
  3. Ran the core permission profile MITM hook parsing tests.
  4. Ran the core config schema fixture test.
  5. Ran the scoped Clippy fixer for the network proxy crate.
  6. Ran the scoped Clippy fixer for the core crate.
  
  ## Notes
  1. Runtime enforcement moved to #20659.
  2. User facing PermissionProfile TOML shape remains in #18240.

  evawong-oai · 2026-05-20 12:51:12 -07:00
  3d94e24a3d
• Warn on invalid UTF-8 in AGENTS.md files (#23232)

  Fixes #23223.
  
  ## Why
  
  Malformed AGENTS instructions should not fail silently. The reported
  issue had invalid UTF-8 in a global `AGENTS.md`; before this change,
  Codex treated that decode failure like a missing file, so the personal
  instructions disappeared without a user-visible explanation and the
  rollout had no `# AGENTS.md instructions` block.
  
  Project-level AGENTS files already used lossy decoding, so their
  instructions still appeared, but invalid bytes were replaced without
  telling the user. Global and project AGENTS files should behave
  consistently: keep usable instruction text when possible, and surface a
  diagnostic when bytes had to be replaced.
  
  ## What changed
  
  Global `AGENTS.override.md` and `AGENTS.md` loading now reads bytes and
  decodes with replacement characters on invalid UTF-8, matching
  project-level AGENTS behavior. Both global and project AGENTS loading
  now emit a startup warning when invalid UTF-8 is found, and both keep
  the instruction text with invalid byte sequences replaced.
  
  Missing files, non-file candidates, empty files, and the existing
  `AGENTS.override.md` before `AGENTS.md` precedence keep their current
  behavior.
  
  ## How users see it
  
  The warnings flow through the existing startup warning surface.
  App-server clients receive config-time startup warnings as
  `configWarning` notifications during initialization, and thread startup
  emits startup warnings as thread-scoped `warning` notifications.
  
  Global AGENTS invalid UTF-8 warnings can appear on both surfaces.
  Project-level AGENTS invalid UTF-8 warnings are discovered while
  building thread instructions, so they appear as thread-scoped `warning`
  notifications. Clients that render warning notifications in the
  conversation surface show the message as a visible diagnostic instead of
  silently hiding or altering instructions.

  Eric Traut · 2026-05-19 21:56:46 -07:00
  9dda71dbae
• feat: add permission profile list api (#23412)

  ## Why
  
  Clients need a typed permission-profile catalog instead of
  reconstructing that state from config internals.
  
  ## What changed
  
  - Added `permissionProfile/list` to the app-server v2 protocol with
  cursor pagination and optional `cwd`.
  - The list response includes built-in permission profiles plus
  config-defined `[permissions.<id>]` profiles from the effective config
  for the request context.
  - Permission profiles keep optional `description` metadata for display
  purposes.
  - App-server docs and schema fixtures are updated for the new RPC.

  viyatb-oai · 2026-05-20 02:42:56 +00:00
  c3faea0b09
• 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
• Make deny canonical for filesystem permission entries (#23493)

  ## Why
  Filesystem permission profiles used `none` for deny-read entries, which
  is less direct than the action the entry actually represents. This
  change makes `deny` the canonical filesystem permission spelling while
  preserving compatibility for older configs that still send `none`.
  
  ## What changed
  - rename `FileSystemAccessMode::None` to `Deny`
  - serialize and generate schemas with `deny` as the canonical value
  - retain `none` only as a legacy input alias for temporary config
  compatibility
  - update filesystem glob diagnostics and regression coverage to use the
  canonical spelling
  - refresh config and app-server schema fixtures to match the new wire
  shape
  
  ## Validation
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core config_toml_deserializes_permission_profiles
  --lib`
  - `cargo test -p codex-core
  read_write_glob_patterns_still_reject_non_subpath_globs --lib`
  
  Earlier in the session, a broad `cargo test -p codex-core` run reached
  unrelated pre-existing failures in timing/snapshot/git-info tests under
  this environment; the targeted surfaces touched by this PR passed
  cleanly.

  viyatb-oai · 2026-05-19 11:03:47 -07:00
  3c76081876
• Add body_after_prefix auto-compact token limit scope (#22870)

  ## Why
  
  `model_auto_compact_token_limit` has only been able to budget the full
  active context. That makes it hard to set a small "growth since
  compaction" budget for sessions that preserve a large carried window
  prefix: the preserved prefix can consume the whole budget and force
  immediate repeated compaction.
  
  This PR adds an opt-in `body_after_prefix` scope so callers can apply
  `model_auto_compact_token_limit` to sampled output and later growth
  after the current carried prefix, while still forcing compaction before
  the full model context window is exhausted.
  
  ## What changed
  
  - Adds `AutoCompactTokenLimitScope` with the existing `total` behavior
  as the default and a new `body_after_prefix` mode:
  [`config_types.rs`](https://github.com/openai/codex/blob/973806b1cb35792555bead994cb3ed94656eb171/codex-rs/protocol/src/config_types.rs#L24-L37).
  - Threads `model_auto_compact_token_limit_scope` through config loading,
  `Config`, `core-api`, and app-server v2 schema/TypeScript generation.
  - Records the first observed input-token count for a `body_after_prefix`
  compaction window and uses it as the baseline when deciding whether the
  scoped auto-compaction budget is exhausted:
  [`turn.rs`](https://github.com/openai/codex/blob/973806b1cb35792555bead994cb3ed94656eb171/codex-rs/core/src/session/turn.rs#L743-L781).
  - Keeps a hard context-window cap in `body_after_prefix`, so scoped
  budgeting cannot let the active context overrun the usable window.
  
  ## Verification
  
  Added compact-suite coverage for the two key behaviors:
  `body_after_prefix` does not re-compact just because the carried prefix
  is larger than the scoped budget, and it still compacts when the total
  active context reaches the configured context window:
  [`compact.rs`](https://github.com/openai/codex/blob/973806b1cb35792555bead994cb3ed94656eb171/codex-rs/core/tests/suite/compact.rs#L3003-L3128).

  jif-oai · 2026-05-19 10:19:46 +00:00
  80fdd4688f
• core: expose permission profile picker metadata (#22928)

  ## Why
  
  The `/permissions` picker needs a config-level way to distinguish legacy
  anonymous presets from named permission-profile mode. That signal cannot
  be inferred reliably in the TUI, especially for the edge case where
  `default_permissions = ":workspace"` is present without a
  `[permissions]` table.
  
  ## What changed
  
  - Expose whether the merged config is explicitly in permission-profile
  mode.
  - Expose the configured custom permission profile IDs alongside the
  built-in profile semantics.
  - Add regression coverage for profile mode detection and custom profile
  metadata, including the `default_permissions = ":workspace"` case.
  - Update the thread-manager sample config literal to match the expanded
  config shape.
  
  ## Stack
  
  1. **This PR**: config metadata needed by downstream permission-profile
  consumers.
  2. [#22931](https://github.com/openai/codex/pull/22931): refresh active
  permission profiles through runtime/session/network state.
  3. [#21559](https://github.com/openai/codex/pull/21559): switch
  `/permissions` to the profile-aware TUI picker.
  
  ## Verification
  
  - `cargo check -p codex-thread-manager-sample`
  - `cargo test -p codex-core
  default_permissions_can_select_builtin_profile_without_permissions_table`
  - `cargo test -p codex-core
  permissions_profiles_allow_direct_write_roots_outside_workspace_root`

  viyatb-oai · 2026-05-18 23:26:17 -07:00
  3009e23644
• Include plugin id in plugin MCP tool metadata (#23353)

  Adding the id of the plugin that contains the MCP (if any) so we can
  apply filters at plugin level.
  
  ## Summary
  - carry the plugin owner into MCP runtime provenance
  - attach `plugin_id` to outbound plugin-backed MCP tool-call `_meta`
  - avoid misattributing user-configured MCP servers that shadow plugin
  server names
  
  ## Testing
  - `just fmt`
  - `just fix -p codex-mcp`
  - `just fix -p codex-core`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-core
  plugin_mcp_tool_call_request_meta_includes_plugin_id`
  - `cargo test -p codex-core
  to_mcp_config_omits_plugin_id_when_user_server_shadows_plugin_mcp`
  - `cargo test -p codex-core
  rebuild_preserving_session_layers_refreshes_plugin_derived_mcp_config`
  - `git diff --check`
  
  ## Notes
  - Attempted `cargo test -p codex-core`; it aborted in
  `agent::control::tests::resume_agent_from_rollout_skips_descendants_when_parent_resume_fails`
  with a stack overflow before the full suite completed.

  Matthew Zeng · 2026-05-18 15:33:33 -07:00
  a66e0e9c4b
• codex: route global AGENTS reads through LOCAL_FS (#23343)

  ## Summary
  - make `load_global_instructions` read through an `ExecutorFileSystem`
  - call global AGENTS reads with explicit `LOCAL_FS` so they stay tied to
  local codex-home state
  
  ## Validation
  - `bazel test --bes_backend= --bes_results_url=
  --test_filter=instruction_sources_include_global_before_agents_md_docs
  //codex-rs/core:core-unit-tests` on `dev`

  starr-openai · 2026-05-18 19:26:10 +00:00
  10f7dc6eb5
• Make multi-agent v2 tool namespace configurable (#23147)

  ## Summary
  - Add `features.multi_agent_v2.tool_namespace` with config/schema
  validation for Responses-compatible namespace values.
  - Thread the resolved namespace into `ToolsConfig` for normal turns and
  review turns.
  - Wrap MultiAgentV2 tool specs and registry names in the configured
  namespace when namespace tools are supported, while falling back to the
  plain tool names when they are not.
  
  ## Validation
  - `just fmt`
  - `just write-config-schema`
  - `cargo test -p codex-features multi_agent_v2_feature_config --
  --nocapture`
  - `cargo test -p codex-core test_build_specs_multi_agent_v2 --
  --nocapture`
  - `cargo test -p codex-core multi_agent_v2_config -- --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_rejects_invalid_tool_namespace -- --nocapture`
  - `cargo test -p codex-tools`
  - `git diff --check`

  jif-oai · 2026-05-17 15:27:43 +02:00
  545ede569c
• test: construct permission profiles directly (#23030)

  ## Why
  
  `SandboxPolicy` is now a legacy compatibility shape, but several tests
  still built a `SandboxPolicy` only to immediately convert it into
  `PermissionProfile` for APIs that already accept canonical runtime
  permissions. Those detours make it harder to audit where legacy sandbox
  policy is still required, because boundary-only usages are mixed
  together with ordinary test setup.
  
  ## What Changed
  
  - Updated tests in `codex-core`, `codex-exec`, `codex-analytics`, and
  `codex-config` to construct `PermissionProfile` values directly when the
  code under test takes a permission profile.
  - Changed exec-policy, request-permissions, session, and sandbox test
  helpers to pass `PermissionProfile` through instead of converting from
  `SandboxPolicy` internally.
  - Left `SandboxPolicy` in place where tests are explicitly exercising
  legacy compatibility or request/response boundaries.
  
  ## Test Plan
  
  - `cargo test -p codex-analytics -p codex-config`
  - `cargo test -p codex-core --lib safety::tests`
  - `cargo test -p codex-core --lib exec_policy::tests::`
  - `cargo test -p codex-core --lib exec::tests`
  - `cargo test -p codex-core --lib guardian_review_session_config`
  - `cargo test -p codex-core --lib tools::network_approval::tests`
  - `cargo test -p codex-core --lib
  tools::runtimes::shell::unix_escalation::tests`
  - `cargo test -p codex-core --lib managed_network`
  - `cargo test -p codex-core --test all request_permissions::`
  - `cargo test -p codex-exec sandbox`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23030).
  * #23036
  * __->__ #23030

  Michael Bolin · 2026-05-16 12:12:37 -07:00
  d91bc15618