58 Commits

• Add feature-gated standalone image generation extension (#24723)

  ## Why
  
  Add a standalone image generation path that can be exercised
  independently of hosted Responses image generation, while retaining the
  hosted tool as fallback unless the extension is actually available to
  the model.
  
  ## What changed
  
  - Added the `codex-image-generation-extension` crate with standalone
  generate/edit execution, prior-image selection for edits, model-visible
  image output, and local generated-image persistence.
  - Installed the extension in app-server behind the disabled-by-default
  `imagegenext` feature and backend eligibility checks.
  - Updated core tool planning so eligible `image_gen.imagegen` exposure
  replaces hosted `image_generation`, while unavailable configurations
  retain hosted fallback.
  - Added coverage for extension behavior, edit history reuse, feature
  gating, auth eligibility, and hosted-tool replacement.
  - The extension is installed through app-server only in this PR; other
  execution paths retain hosted image generation because hosted
  replacement occurs only when the standalone executor is actually
  registered and model-visible.
  - The initial extension contract intentionally fixes the image model to
  `gpt-image-2` and uses automatic image parameters.
  - Native generated-image history/card parity and rollout persistence
  cleanup are intentionally deferred follow-up work.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-features`
  - `just test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`
  - `just test -p codex-app-server`
  - `just fix -p codex-image-generation-extension -p codex-features -p
  codex-core -p codex-app-server`
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Won Park · 2026-05-28 11:44:55 -07:00
  ecb41fcb64
• TUI: Unified mentions tweaks + polish mentions rendering (#23363)

  This change keeps unified @mentions behind the mentions_v2 gate, moves
  the flag to under-development, and polishes mention rendering/history
  behavior.
  
  It also adds a few small improvements to the mentions feature around
  mention rendering and history round-tripping for plugin/tool mentions in
  message edit scenarios. Plugin selections now insert `@` mentions with
  better casing, and saved history preserves the visible sigil so recalled
  messages look the same as what the user typed.
  
  - Preserves `@` sigils when encoding/decoding mention history for
  tool/plugin paths.
  - Improves plugin mention insertion so display names/casing are
  reflected more cleanly in the composer.
  - Update composer to render user-entered plugin mentions in the same
  color as the mentions menu. ALso applies to recalled/edited messages.
  - Left/right arrows no longer switch unified-mention search modes after
  an @mention has already been accepted (Ex: arrowing left through a
  composed message that contains @mentions).
  - Keeps bound mentions stable around punctuation, so accepted `@`
  mentions do not reopen the popup and punctuated `$` mentions still
  persist to cross-session history.
  
  **Steps to test**
  - Ensure mentions_v2 is enabled through configuration or `--enable
  mentions_v2`
  - Type `@` in the TUI composer and verify filesystem/plugin/skill
  results are displayed in the unified mentions menu.
  - Select a plugin mention from the `@` popup and confirm the inserted
  text is an `@...` mention with casing, then recall/edit the message and
  confirm it still renders as `@...`.
  - Mention a skill and verify that skills still insert as `$skill`
  mentions rather than `@` mentions.
  - Verify punctuated mentions such as `@plugin.` and `($skill)` keep
  their bound mention behavior across editing and history recall.

  canvrno-oai · 2026-05-28 10:30:15 -07:00
  6c1215dac6
• 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
• Remove ToolSearch feature toggle (#23389)

  ## Summary
  - mark `ToolSearch` as removed and ignore stale config writes for its
  legacy key
  - make search tool exposure depend only on model capability, not a
  feature toggle
  - remove app-server enablement support and prune now-obsolete test
  coverage/setup
  
  ## Verification
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core search_tool_requires_model_capability`
  - `cargo test -p codex-app-server experimental_feature_enablement_set_`
  
  ## Notes
  - This keeps the legacy config key as a no-op for compatibility while
  removing the ability to toggle the behavior off cleanly.
  - No developer-facing docs update outside the touched app-server README
  was needed.

  sayan-oai · 2026-05-19 01:24:39 +00:00
  daa11820b0
• 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
• chore(features) rm Feature::ApplyPatchFreeform (#22711)

  ## Summary
  Removes the feature since this is effectively on by default in all cases
  where we should use it, or can be configured via models.json.
  
  ## Testing
  - [x] unit tests pass

  Dylan Hurd · 2026-05-14 16:15:56 -07:00
  51b0e94105
• enable/disable remote control at runtime, not via features (#22578)

  ## Why
  reapplies https://github.com/openai/codex/pull/22386 which was
  previously reverted
  
  Also, introduce `remoteControl/enable` and `remoteControl/disable`
  app-server APIs to toggle on/off remote control at runtime for a given
  running app-server instance.
  
  ## What Changed
  
  - Adds experimental v2 RPCs:
    - `remoteControl/enable`
    - `remoteControl/disable`
  - Adds `RemoteControlRequestProcessor` and routes the new RPCs through
  it instead of `ConfigRequestProcessor`.
  - Adds named `RemoteControlHandle::enable`, `disable`, and `status`
  methods.
  - Makes `remoteControl/enable` return an error when sqlite state DB is
  unavailable, while keeping enrollment/websocket failures as async status
  updates.
  - Adds `AppServerRuntimeOptions.remote_control_enabled` and hidden
  `--remote-control` flags for `codex app-server` and `codex-app-server`.
  - Updates managed daemon startup to use `codex app-server
  --remote-control --listen unix://`.
  - Marks `Feature::RemoteControl` as removed and ignores
  `[features].remote_control`.
  - Updates app-server README entries for the new remote-control methods.

  Owen Lin · 2026-05-14 01:07:46 +00:00
  4e368aa2e9
• chore(config) rm experimental_use_freeform_apply_patch (#22565)

  ## Summary
  Get rid of the `experimental_use_freeform_apply_patch` config option,
  since it is now encoded in model config. No deprecation message since it
  has been experimental this entire time.
  
  ## Testing
  - [x] Updated unit tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-05-13 17:52:15 -07:00
  e33cf9ae28
• Make multi_agent_v2 wait_agent timeouts configurable (#22528)

  ## Why
  
  `multi_agent_v2` already allowed configuring the minimum `wait_agent`
  timeout, but the default timeout and upper bound were still hard-coded.
  That made it hard to tune waits for subagent mailbox activity in
  sessions that need either faster wakeups or longer waits, and it meant
  the model-visible `wait_agent` schema could not fully reflect the
  resolved runtime limits.
  
  ## What Changed
  
  - Added `features.multi_agent_v2.max_wait_timeout_ms` and
  `features.multi_agent_v2.default_wait_timeout_ms` alongside the existing
  `min_wait_timeout_ms` setting.
  - Validated all three timeouts in config as `0..=3_600_000`, with
  `min_wait_timeout_ms <= default_wait_timeout_ms <= max_wait_timeout_ms`.
  - Thread and review session tool config now passes the resolved
  min/default/max values into the `wait_agent` tool schema.
  - `wait_agent` now uses the configured default when `timeout_ms` is
  omitted and rejects explicit values outside the configured min/max range
  instead of silently clamping them.
  - Updated the generated config schema and config-lock test coverage for
  the new fields.

  Andrey Mishchenko · 2026-05-13 14:43:06 -07:00
  7c57a59f51
• Enable plugin hooks by default (#22549)

  # Why
  
  Plugin-bundled hooks are already wired through the plugin manager,
  session setup, and app-server hook listing paths. Keeping `plugin_hooks`
  disabled by default means users still need an explicit feature opt-in
  before that existing behavior participates in normal plugin loading.
  
  # What
  
  - mark `plugin_hooks` as stable and enable it by default
  - add feature-registry test coverage for the new default/stage pairing
  
  Validation:
  
  - `cargo test -p codex-features`
  - `just fmt`

  Abhinav · 2026-05-13 21:10:28 +00:00
  14473c216f
• feat: expose multi-agent v2 as model-only tools (#22514)

  ## Why
  
  `code_mode_only` filters code-mode nested tools out of the top-level
  tool list. For multi-agent v2, we need a rollout shape where the
  collaboration tools remain callable as normal model tools without also
  being embedded into the code-mode `exec` tool declaration.
  
  Related to this:
  https://openai-corpws.slack.com/archives/C0AQLHB4U75/p1778660267922549
  
  ## What Changed
  
  - Adds `features.multi_agent_v2.non_code_mode_only`, including config
  resolution, profile override handling, and generated schema coverage.
  - Introduces `ToolExposure::DirectModelOnly` so a tool can be included
  in the initial model-visible list while staying out of the nested
  code-mode tool surface.
  - Applies that exposure to the multi-agent v2 tools when the new flag is
  set: `spawn_agent`, `send_message`, `followup_task`, `wait_agent`,
  `close_agent`, and `list_agents`.
  - Updates code-mode-only filtering so direct-model-only tools remain
  visible while ordinary nested code-mode tools are still hidden.
  
  ## Verification
  
  - Added config parsing/profile tests for `non_code_mode_only`.
  - Added tool spec coverage for the code-mode-only multi-agent v2
  exposure behavior.

  jif-oai · 2026-05-13 19:49:47 +02:00
  fc26af377f
• revert: mark Feature::RemoteControl as removed (#22520)

  reverts: https://github.com/openai/codex/pull/22386

  Owen Lin · 2026-05-13 17:32:15 +00:00
  2b3b220605
• mark Feature::RemoteControl as removed (#22386)

  ## Why
  
  `remote_control` can appear in `config.toml`, CLI feature overrides, and
  the app-server config APIs. Before this PR, app-server startup treated
  `config.features.enabled(Feature::RemoteControl)` as the signal to start
  remote control ([base
  code](https://github.com/openai/codex/blob/5e3ee5eddfa5333f2e0b011880abf0cbf92bd295/codex-rs/app-server/src/lib.rs#L678-L680)).
  That meant a user with:
  
  ```toml
  [features]
  remote_control = true
  ```
  
  would accidentally opt every app-server process into remote control.
  Remote-control startup should instead be a per-process launch decision
  made by CLI flags.
  
  ## What Changed
  
  - Marks `Feature::RemoteControl` as `Stage::Removed`, keeping
  `remote_control` as a known compatibility key while making it
  config-inert.
  - Adds a hidden `--remote-control` process flag to `codex app-server`
  and standalone `codex-app-server`.
  - Plumbs that flag through
  `AppServerRuntimeOptions.remote_control_enabled` and makes app-server
  startup use only that runtime option to decide whether to start remote
  control.
  - Removes the app-server config mutation hook that reloaded config and
  toggled remote control at runtime.
  - Updates managed daemon spawning to use `codex app-server
  --remote-control --listen unix://` instead of `--enable remote_control`.
  
  Config APIs can still list, read, write, and set `remote_control`; those
  operations just no longer affect remote-control process enrollment.

  Owen Lin · 2026-05-13 00:52:45 +00:00
  2237a13cf1
• feat: add network proxy feature flag (#20147)

  ## Why
  
  The permissions migration is making
  `permissions.<profile>.network.enabled` the canonical sandbox network
  bit, while proxy startup is a separate concern. Enabling network access
  should not implicitly start the proxy, and users who are still on legacy
  sandbox modes need a separate place to opt into proxy startup and
  provide proxy-specific settings.
  
  This follow-up to #19900 gives the network proxy its own feature surface
  instead of overloading permission-profile network semantics.
  
  ## What changed
  
  - Add an experimental `network_proxy` feature with a configurable
  `[features.network_proxy]` table.
  - Overlay `features.network_proxy` settings onto the configured proxy
  state after permission-profile selection, so the proxy only starts when
  the active `NetworkSandboxPolicy` already allows network access.
  - Preserve `[experimental_network]` startup behavior independently of
  the new feature flag.
  
  ## Behavior and examples
  
  There are now three related knobs:
  
  - `permissions.<profile>.network.enabled` controls whether the active
  permission profile has network access at all.
  - `features.network_proxy` enables proxy restrictions for an
  already-network-enabled profile.
  - Legacy `sandbox_mode` plus `[sandbox_workspace_write].network_access`
  still control whether legacy `workspace-write` has network access at
  all.
  
  The rule is:
  
  - network off + proxy flag on -> network stays off, proxy is a no-op
  - network on + proxy flag off -> unrestricted direct network
  - network on + proxy flag on -> network stays on, with proxy
  restrictions applied
  
  For permission profiles, the feature toggle adds proxy restrictions only
  when network access is already enabled:
  
  ```toml
  default_permissions = "workspace"
  
  [permissions.workspace.filesystem]
  ":minimal" = "read"
  
  [permissions.workspace.network]
  enabled = true
  
  [features]
  network_proxy = true
  ```
  
  If `network.enabled = false`, the same feature flag is a no-op: network
  remains off and the proxy does not start.
  
  For legacy sandbox config, `network_access` remains the master switch:
  
  ```toml
  sandbox_mode = "workspace-write"
  
  [sandbox_workspace_write]
  network_access = true
  
  [features]
  network_proxy = true
  ```
  
  That keeps legacy `workspace-write` network access on, but routes it
  through the proxy policy. If `network_access = false`, the proxy feature
  is a no-op and legacy `workspace-write` remains offline.
  
  The same proxy opt-in can be supplied from the CLI:
  
  ```bash
  codex -c 'features.network_proxy=true'
  ```
  
  Additional proxy settings can be supplied when a table is needed:
  
  ```bash
  codex \
    -c 'features.network_proxy.enabled=true' \
    -c 'features.network_proxy.enable_socks5=false'
  ```
  
  The intended behavior matrix is:
  
  | Config surface | Network setting | `features.network_proxy` | Direct
  sandbox network | Proxy |
  | --- | --- | --- | --- | --- |
  | Permission profile | `network.enabled = false` | off | restricted |
  off |
  | Permission profile | `network.enabled = false` | on | restricted | off
  |
  | Permission profile | `network.enabled = true` | off | enabled | off |
  | Permission profile | `network.enabled = true` | on | enabled | on |
  | Legacy `workspace-write` | `network_access = false` | off | restricted
  | off |
  | Legacy `workspace-write` | `network_access = false` | on | restricted
  | off |
  | Legacy `workspace-write` | `network_access = true` | off | enabled |
  off |
  | Legacy `workspace-write` | `network_access = true` | on | enabled | on
  |
  
  `[experimental_network]` requirements remain separate from the user
  feature toggle and still start the proxy on their own.
  
  Relevant code:
  -
  [`features/src/feature_configs.rs`](https://github.com/openai/codex/blob/43785aff47/codex-rs/features/src/feature_configs.rs#L58-L117)
  defines the feature-specific proxy config.
  -
  [`core/src/config/mod.rs`](https://github.com/openai/codex/blob/43785aff47/codex-rs/core/src/config/mod.rs#L1959-L1964)
  reads the feature table, and [later applies it only when network access
  is already
  enabled](https://github.com/openai/codex/blob/43785aff47/codex-rs/core/src/config/mod.rs#L2448-L2458).
  
  ## Verification
  
  Added focused coverage for:
  - keeping the proxy off when `features.network_proxy` is enabled but
  sandbox network access is disabled
  - the full permission-profile and legacy `workspace-write` matrix above
  - preserving `[experimental_network]` startup without the feature
  - reusing profile-supplied proxy settings when the feature is enabled
  
  Ran:
  - `cargo test -p codex-features`
  - `cargo test -p codex-core network_proxy_feature`
  - `cargo test -p codex-core
  experimental_network_requirements_enable_proxy_without_feature`

  viyatb-oai · 2026-05-11 14:12:00 -07:00
  c7b55cdc46
• chore: drop built-in MCPs (#22173)

  Drop something that was never used

  jif-oai · 2026-05-11 19:45:08 +02:00
  32b1ae7099
• [codex] Enable apply_patch freeform by default (#21687)

  ## Summary
  - enable `apply_patch_freeform` by default in the feature registry
  
  ## Why
  - make the freeform `apply_patch` tool available by default when model
  metadata does not explicitly opt into another mode
  
  ## Validation
  - `just fmt`
  - did not run tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 13:15:00 +00:00
  cce059467a
• [codex] Add response.processed websocket request (#21284)

  ## Summary
  
  - Add a `response.processed` websocket request payload and sender for
  Responses API websockets.
  - Send `response.processed` from `try_run_sampling_request` after a
  response completes, local turn processing succeeds, and the
  session-owned feature flag is enabled.
  - Add websocket coverage for both enabled and disabled feature-flag
  behavior.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core response_processed`
  - `cargo test -p codex-api responses_websocket`
  - `cargo test -p codex-features
  responses_websocket_response_processed_is_under_development`
  - `git diff --check`
  - `just fix -p codex-api -p codex-core -p codex-features`
  - `git diff --check origin/main...HEAD`

  pakrym-oai · 2026-05-06 09:58:46 -07:00
  2070d5bfd3
• chore: spawn MCP for memories (#21214)

  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 15:05:54 +02:00
  ca257b6ce5
• Support Codex Apps auth elicitations (#19193)

  ## Summary
  
  - request URL-mode MCP elicitations when Codex Apps tool calls fail with
  connector auth metadata
  - route Codex Apps auth URL elicitations into the TUI app-link flow
  
  ## Test plan
  
  - `just fmt`
  - `cargo test -p codex-core mcp_tool_call::tests`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-tui bottom_pane::app_link_view::tests`
  - `just fix -p codex-core`
  - `just fix -p codex-mcp`
  - `just fix -p codex-tui`
  
  Also attempted broader local runs:
  
  - `cargo test -p codex-core` fails in unrelated
  config/request-permission/proxy-sensitive tests under the current Codex
  Desktop environment.
  - `cargo test -p codex-tui` fails in unrelated status
  snapshots/trust-default tests because the ambient environment renders
  workspace-write/network permission defaults.

  Matthew Zeng · 2026-05-06 07:18:00 +00:00
  f9a907aebe
• feat: add remote compaction v2 Responses client path (#20773)

  ## Why
  
  This adds the `remote_compaction_v2` client path so remote compaction
  can run through the normal Responses stream and install a
  `context_compaction` item that trigger a compaction.
  
  The goal is to migrate some of the compaction logic on the client side
  
  We keeps the v2 transport behind a feature flag while letting follow-up
  requests reuse the compacted context instead of falling back to the
  legacy compaction item shape.
  
  ## What changed
  
  - add `ResponseItem::ContextCompaction` and refresh the generated
  app-server / schema / TypeScript fixtures that expose response items on
  the wire
  - add `core/src/compact_remote_v2.rs` to send compaction through the
  standard streamed Responses client, require exactly one
  `context_compaction` output item, and install that item into compacted
  history
  - route manual compact and auto-compaction through the v2 path when
  `remote_compaction_v2` is enabled, while keeping the existing remote
  compaction path as the fallback
  - preserve the new item type across history retention, follow-up request
  construction, telemetry, rollout persistence, and rollout-trace
  normalization
  - add targeted coverage for the feature flag, `context_compaction`
  serialization, rollout-trace normalization, and remote-compaction
  follow-up behavior
  
  ## Verification
  
  - added protocol tests for `context_compaction`
  serialization/deserialization in `protocol/src/models.rs`
  - added rollout-trace coverage for `context_compaction` normalization in
  `rollout-trace/src/reducer/conversation_tests.rs`
  - added remote compaction integration coverage for v2 follow-up reuse
  and mixed compaction output streams in
  `core/tests/suite/compact_remote.rs`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-04 14:15:01 +02:00
  d927f61208
• feat: export and replay effective config locks (#20405)

  ## Why
  
  For reproducibility. A hand-written `config.toml` is not enough to
  recreate what a Codex session actually ran with because layered config,
  CLI overrides, defaults, feature aliases, resolved feature config,
  prompt setup, and model-catalog/session values can all affect the final
  runtime behavior.
  
  This PR adds an effective config lockfile path: one run can export the
  resolved session config, and a later run can replay that lockfile and
  fail early if the regenerated effective config drifts.
  
  ## What Changed
  
  - Add a dedicated `ConfigLockfileToml` wrapper with top-level lockfile
  metadata plus the replayable config:
  
    ```toml
    version = 1
    codex_version = "..."
  
    [config]
    # effective ConfigToml fields
    ```
  
  - Keep lockfile metadata out of regular `ConfigToml`; replay loads
  `ConfigLockfileToml` and then uses its nested `config` as the
  authoritative config layer.
  - Add `debug.config_lockfile.export_dir` to write
  `<thread_id>.config.lock.toml` when a root session starts.
  - Add `debug.config_lockfile.load_path` to replay a saved lockfile and
  validate the regenerated session lockfile against it.
  - Add `debug.config_lockfile.allow_codex_version_mismatch` to optionally
  tolerate Codex binary version drift while still comparing the rest of
  the lockfile.
  - Add `debug.config_lockfile.save_fields_resolved_from_model_catalog` so
  lock creation can either save model-catalog/session-resolved fields or
  intentionally leave those fields dynamic.
  - Build lockfiles from the effective config plus resolved runtime values
  such as model selection, reasoning settings, prompts, service tier, web
  search mode, feature states/config, memories config, skill instructions,
  and agent limits.
  - Materialize feature aliases and custom feature config into the
  lockfile so replay compares canonical resolved behavior instead of
  user-authored alias shape.
  - Strip profile/debug/file-include/environment-specific inputs from
  generated lockfiles so they contain replayable values rather than the
  inputs that produced those values.
  - Surface JSON-RPC server error code/data in app-server client and TUI
  bootstrap errors so config-lock replay failures include the actual TOML
  diff.
  - Regenerate the config schema for the new debug config keys.
  
  ## Review Notes
  
  The main flow is split across these files:
  
  - `config/src/config_toml.rs`: lockfile/debug TOML shapes.
  - `core/src/config/mod.rs`: loading `debug.config_lockfile.*`, replaying
  a lockfile as a config layer, and preserving the expected lockfile for
  validation.
  - `core/src/session/config_lock.rs`: exporting the current session
  lockfile and materializing resolved session/config values.
  - `core/src/config_lock.rs`: lockfile parsing, metadata/version checks,
  replay comparison, and diff formatting.
  
  ## Usage
  
  Export a lockfile from a normal session:
  
  ```sh
  codex -c 'debug.config_lockfile.export_dir="/tmp/codex-locks"'
  ```
  
  Export a lockfile without saving model-catalog/session-resolved fields:
  
  ```sh
  codex -c 'debug.config_lockfile.export_dir="/tmp/codex-locks"' \
    -c 'debug.config_lockfile.save_fields_resolved_from_model_catalog=false'
  ```
  
  Replay a saved lockfile in a later session:
  
  ```sh
  codex -c 'debug.config_lockfile.load_path="/tmp/codex-locks/<thread_id>.config.lock.toml"'
  ```
  
  If replay resolves to a different effective config, startup fails with a
  TOML diff.
  
  To tolerate Codex binary version drift during replay:
  
  ```sh
  codex -c 'debug.config_lockfile.load_path="/tmp/codex-locks/<thread_id>.config.lock.toml"' \
    -c 'debug.config_lockfile.allow_codex_version_mismatch=true'
  ```
  
  ## Limitations
  
  This does not support custom rules/network policies.
  
  ## Verification
  
  - `cargo test -p codex-core config_lock`
  - `cargo test -p codex-config`
  - `cargo test -p codex-thread-manager-sample`

  jif-oai · 2026-05-01 17:46:02 +02:00
  0b04d1b3cc
• Alias codex_hooks feature as hooks (#20522)

  # Why
  
  The hooks feature flag should use the concise canonical name `hooks`,
  while existing configs that still use `codex_hooks` continue to work
  during the rename.
  
  # What
  
  - change the canonical `Feature::CodexHooks` key from `codex_hooks` to
  `hooks`
  - register `codex_hooks` through the existing legacy-alias path
  - update the config schema and canonical config fixtures to prefer
  `hooks`
  - add regression coverage that both `hooks` and `codex_hooks` resolve to
  `Feature::CodexHooks`
  
  # Verification
  
  - `cargo test -p codex-features`
  - `cargo test -p codex-core config::schema_tests`
  - `cargo test -p codex-core
  pre_tool_use_blocks_shell_when_defined_in_config_toml`
  - `cargo test -p codex-app-server
  hooks_list_uses_each_cwds_effective_feature_enablement`

  Abhinav · 2026-05-01 00:46:33 +00:00
  0d9a5d20ec
• [Codex] Add browser use external feature flag (#20245)

  ## Summary
  
  - Adds a separate feature control for external-browser Browser Use
  integrations.
  - Registers `browser_use_external` as a stable, default-enabled
  requirements-owned feature key.
  - Updates feature registry tests and regenerates the config schema.
  
  Codex validation:
  - `cargo fmt -- --config imports_granularity=Item`
  - `cargo run -p codex-core --bin codex-write-config-schema`
  - `cargo test -p codex-features`
  
  ## Addendum
  
  This gives enterprise policy a coarse control for Browser Use outside
  the Codex-managed in-app browser. The existing `browser_use` feature is
  the Browser Use control, while `browser_use_external` can gate
  extension/native integrations for external browsers as that surface
  grows

  khoi · 2026-04-30 11:53:19 -07:00
  719431da6e
• Make MultiAgentV2 wait minimum configurable (#20052)

  ## Why
  
  MultiAgentV2 `wait_agent` currently clamps short waits to a fixed 10
  second minimum. That default is still useful for preventing tight
  polling loops, but it is too rigid for environments that need faster
  mailbox wake-up checks or a larger minimum to discourage frequent
  polling.
  
  This PR makes the minimum wait timeout configurable from the existing
  MultiAgentV2 feature config section, so operators can tune the behavior
  without changing the legacy multi-agent tool surface.
  
  ## What Changed
  
  - Added `features.multi_agent_v2.min_wait_timeout_ms`.
  - Defaulted the new setting to the existing 10 second floor.
  - Validated the configured value as `1..=3600000`, matching the existing
  one hour maximum wait bound.
  - Applied the configured minimum to MultiAgentV2 `wait_agent` runtime
  clamping.
  - Plumbed the configured minimum into the `wait_agent` tool schema,
  including the effective default when the minimum is above the normal 30
  second default.
  - Regenerated `core/config.schema.json`.
  
  ## Verification
  
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib multi_agent_v2`
  - `just fix -p codex-core`

  jif-oai · 2026-04-28 22:36:44 +02:00
  34d71d43eb
• Add MultiAgentV2 root and subagent context hints (#19805)

  ## Why
  
  MultiAgentV2 sessions need startup guidance that matches the role of the
  thread that is actually being created. Root agents and subagents have
  different responsibilities, and forked subagents can inherit parent
  rollout history. If the parent hint is carried into the child context,
  the child can see stale or conflicting developer guidance before its own
  session-specific context is added.
  
  ## What changed
  
  - Added `features.multi_agent_v2.root_agent_usage_hint_text` and
  `features.multi_agent_v2.subagent_usage_hint_text` config fields,
  including schema/config parsing support.
  - Injected the matching root or subagent hint into the initial context
  as its own developer message when `multi_agent_v2` is enabled.
  - Filtered configured MultiAgentV2 usage-hint developer messages out of
  forked parent history so a child thread receives fresh guidance for its
  own session source/config.
  - Added targeted coverage for config parsing, initial-context rendering,
  feature-config deserialization, and forked-history filtering.
  
  ## Context examples
  
  With this config:
  
  ```toml
  [features.multi_agent_v2]
  enabled = true
  root_agent_usage_hint_text = "Root guidance."
  subagent_usage_hint_text = "Subagent guidance."
  ```
  
  A root thread initial context renders the root hint as a standalone
  developer message:
  
  ```text
  [developer]
  <existing developer context, when present>
  
  [developer]
  Root guidance.
  ```
  
  A subagent thread initial context renders the subagent hint instead:
  
  ```text
  [developer]
  <existing developer context, when present>
  
  [developer]
  Subagent guidance.
  ```
  
  When a subagent forks parent history, any parent developer message whose
  text exactly matches the configured MultiAgentV2 root or subagent hint
  is omitted from the forked history before the child receives its fresh
  subagent hint.

  jif-oai · 2026-04-28 12:31:45 +02:00
  fd36838cf3
• Remove ghost snapshots (#19481)

  ## Summary
  - Remove `ghost_snapshot` / `GhostCommit` from the Responses API surface
  and generated SDK/schema artifacts.
  - Keep legacy config loading compatible, but make undo a no-op that
  reports the feature is unavailable.
  - Clean up core history, compaction, telemetry, rollout, and tests to
  stop carrying ghost snapshot items.
  
  ## Testing
  - Unit tests passed for `codex-protocol`, `codex-core` targeted undo and
  compaction flows, `codex-rollout`, and `codex-app-server-protocol`.
  - Regenerated config and app-server schemas plus Python SDK artifacts
  and verified they match the checked-in outputs.

  pakrym-oai · 2026-04-27 18:48:57 -07:00
  4e05f3053c
• [codex-analytics] remove ga flag (#19863)
  rhan-oai · 2026-04-27 19:29:19 +00:00
  215d5a8f7c
• multi_agent_v2: move thread cap into feature config (#19792)

  ## Why
  
  `features.multi_agent_v2.max_concurrent_threads_per_session` is meant to
  be the MultiAgentV2-specific session thread cap: it counts the root
  thread and all open subagent threads. The previous implementation kept
  this surface tied to `agents.max_threads`, which made it a global
  subagent-only cap and allowed the legacy setting to coexist with
  MultiAgentV2.
  
  ## What Changed
  
  - Added `max_concurrent_threads_per_session` to
  `[features.multi_agent_v2]` with default `4`.
  - Removed the `[agents] max_concurrent_threads_per_session` alias to
  `agents.max_threads`.
  - When MultiAgentV2 is enabled, reject `agents.max_threads` and derive
  the existing internal subagent slot limit as
  `max_concurrent_threads_per_session - 1`.
  - Regenerated `core/config.schema.json` and added coverage for the new
  config semantics.
  
  ## Result
  ```
  ➜  codex git:(jif/clean-multi-agent-v2-config) codex -c features.multi_agent_v2.enabled=true -c features.multi_agent_v2.max_concurrent_threads_per_session=3
  ╭────────────────────────────────────────────────────╮
  │ >_ OpenAI Codex (v0.0.0)                           │
  │                                                    │
  │ model:     gpt-5.5 xhigh   fast   /model to change │
  │ directory: ~/code/codex                            │
  ╰────────────────────────────────────────────────────╯
  
    Tip: Update Required - This version will no longer be supported starting May 8th. Please upgrade to the latest version (https://github.com/openai/codex/releases/latest) using your preferred package manager.
  
  › Can you try to spawn 4 agents
  
  
  • I’ll try to start four lightweight agents at once and report exactly what the runtime accepts.
  
  • Spawned Russell [no-apps] (gpt-5.5 xhigh)
    └ Spawn probe 1: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Spawned Descartes [no-apps] (gpt-5.5 xhigh)
    └ Spawn probe 2: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Agent spawn failed
    └ Spawn probe 3: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Agent spawn failed
    └ Spawn probe 4: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • The runtime accepted the first two and rejected the next two with agent thread limit reached. I’m checking whether the two accepted probes have returned cleanly, then I’ll close them if needed.
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-27 13:31:56 +02:00
  f8c527e529
• fix(tui): reflow scrollback on terminal resize (#18575)

  Fixes multiple scrollback and terminal resize issues: #5538, #5576,
  #8352, #12223, #16165, and #15380.
  
  ## Why
  
  Codex writes finalized transcript output into terminal scrollback after
  wrapping it for the current viewport width. A later terminal resize
  could leave that scrollback shaped for the old width, so wider windows
  kept narrow output and narrower windows could show stale wrapping
  artifacts until enough new output replaced the visible area.
  
  This is also the foundation PR for responsive markdown tables. Table
  rendering needs finalized transcript content to be width-sensitive after
  insertion, not only while content is first streaming. Markdown table
  rendering itself stays in #18576.
  
  ## Stack
  
  - PR1: resize backlog reflow and interrupt cleanup
  - #18576: markdown table support
  
  ## What Changed
  
  - Rebuild source-backed transcript history when the terminal width
  changes. `terminal_resize_reflow` is introduced through the experimental
  feature system, but is enabled by default for this rollout so we can
  validate behavior across real terminals.
  - Preserve assistant and plan stream source so finalized streaming
  output can participate in resize reflow after consolidation.
  - Debounce resize work, but force a final source-backed reflow when a
  resize happened during active or unconsolidated streaming output.
  - Clear stale pending history lines on resize so old-width wrapped
  output is not emitted just before rebuilt scrollback.
  - Bound replay work with `[tui.terminal_resize_reflow].max_rows`:
  omitted uses terminal-specific defaults, `0` keeps all rendered rows,
  and a positive value sets an explicit cap. The cap applies both while
  initially replaying a resumed transcript into scrollback and when
  rebuilding scrollback after terminal resize.
  - Consolidate interrupted assistant streams before cleanup, then clear
  pending stream output and active-tail state consistently.
  - Move resize reflow and thread event buffering helpers out of `app.rs`
  into dedicated TUI modules.
  - Add focused coverage for resize reflow, feature-gated behavior,
  streaming source preservation, interrupted output cleanup,
  unicode-neutral text, terminal-specific row caps, and composer/layout
  stability.
  
  ## Runtime Bounds
  
  Resize reflow keeps only the most recent rendered rows when a row cap is
  active. The default is `auto`, which maps to the detected terminal's
  default scrollback size where Codex can identify it: VS Code `1000`,
  Windows Terminal `9001`, WezTerm `3500`, and Alacritty `10000`.
  Terminals without a dedicated mapping use the conservative fallback of
  `1000` rows. Users can override this with `[tui.terminal_resize_reflow]
  max_rows = N`, or set `max_rows = 0` to disable row limiting.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui reflow`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui
  transcript_reflow`
  - `just fix -p codex-tui`
  - PR CI in progress on the squashed branch

  Felipe Coury · 2026-04-25 22:00:32 -03:00
  5591912f0b
• Enable unavailable dummy tools by default (#19459)

  ## Summary
  - Mark `unavailable_dummy_tools` as a stable feature and enable it by
  default
  - Update the feature registry test to match the new default state
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-features`

  Matthew Zeng · 2026-04-25 08:46:57 +00:00
  6e838a19fa
• Remove js_repl feature (#19410)
  Curtis 'Fjord' Hawthorne · 2026-04-24 17:49:29 -07:00
  8a559e7938
• Add computer_use feature requirement key (#19071)

  ## Summary
  - add the `computer_use` requirements-only feature key
  - include it in generated config schema output
  - cover the new key in feature metadata tests
  
  ## Testing
  - `cargo test -p codex-features`
  - `just write-config-schema`
  - `just fmt`
  - `just fix -p codex-features`
  
  cc @xl-openai
  
  ---------
  
  Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>

  Leo Shimonaka · 2026-04-22 22:49:26 -07:00
  7730fb3ab8
• chore(auto-review) feature => stable (#19063)

  ## Summary
  Turn on Auto Review
  
  ## Testing
  - [x] Update unit tests

  Dylan Hurd · 2026-04-22 18:51:39 -07:00
  c6ab601824
• [Codex] Register browser requirements feature keys (#18956)

  ## Summary
  - register `in_app_browser` and `browser_use` as stable feature keys
  - allow requirements/MDM feature requirements to pin those desktop
  browser controls
  - add coverage for browser requirements being accepted by config loading
  
  ## Testing
  - `cargo fmt --all` (`just fmt` unavailable locally; rustfmt warned
  about nightly-only `imports_granularity` config)
  - `cargo test -p codex-features`
  - `cargo test -p codex-core browser_feature_requirements_are_valid`
  - Tested manually by setting in `requirements.toml` and seeing after app
  restart state to reflect the setting was correct (at the time hiding the
  `Browser Use` setting when the enterprise setting was set to false

  khoi · 2026-04-22 15:27:15 -07:00
  568cdacc7e
• fix: fully revert agent identity runtime wiring (#18757)

  ## Summary
  
  This PR fully reverts the previously merged Agent Identity runtime
  integration from the old stack:
  https://github.com/openai/codex/pull/17387/changes
  
  It removes the Codex-side task lifecycle wiring, rollout/session
  persistence, feature flag plumbing, lazy `auth.json` mutation,
  background task auth paths, and request callsite changes introduced by
  that stack.
  
  This leaves the repo in a clean pre-AgentIdentity integration state so
  the follow-up PRs can reintroduce the pieces in smaller reviewable
  layers.
  
  ## Stack
  
  1. This PR: full revert
  2. https://github.com/openai/codex/pull/18871: move Agent Identity
  business logic into a crate
  3. https://github.com/openai/codex/pull/18785: add explicit
  AgentIdentity auth mode and startup task allocation
  4. https://github.com/openai/codex/pull/18811: migrate auth callsites
  through AuthProvider
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-21 14:30:55 -07:00
  be75785504
• feat: chronicle alias (#18651)

  Rename Telepathy to Chronicle and add an alias for backward
  compatibility

  jif-oai · 2026-04-20 11:52:21 +01:00
  1c24347772
• [TUI] add external config migration prompt when start TUI (#17891)

  - add a TUI startup migration prompt for external agent config
  - support migrating external configs including config, skills, AGENTS.md
  and plugins
  - gate the prompt behind features.external_migrate (default false)
  
  <img width="1037" height="480" alt="Screenshot 2026-04-14 at 9 29 14 PM"
  src="https://github.com/user-attachments/assets/6060849b-03cb-429a-9c13-c7bb46ad2e65"
  />
  <img width="713" height="183" alt="Screenshot 2026-04-14 at 9 29 26 PM"
  src="https://github.com/user-attachments/assets/d13f177e-d4c4-479c-8736-ef29636081e1"
  />
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  alexsong-oai · 2026-04-17 17:58:32 -07:00
  93ff798e5b
• Guardian -> Auto-Review (#18021)

  This PR is a user-facing change for our rebranding of guardian to
  auto-review.

  Won Park · 2026-04-17 09:56:24 -07:00
  af7b8d551c
• fix: deprecate use_legacy_landlock feature flag (#17971)

  ## Summary
  - mark `features.use_legacy_landlock` as a deprecated feature flag
  - emit a startup deprecation notice when the flag is configured
  - add feature- and core-level regression coverage for the notice
  
  
  <img width="1288" height="93" alt="Screenshot 2026-04-15 at 11 14 00 PM"
  src="https://github.com/user-attachments/assets/fffc628b-614c-4521-9374-64e50a269252"
  />
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-16 17:37:15 -07:00
  2967900d81
• Launch image generation by default (#17153)

  ## Summary
  - Promote `image_generation` from under-development to stable
  - Enable image generation by default in the feature registry
  - Update feature coverage for the new launch-state expectation
  - Add the missing image-generation auth fixture field in a tool registry
  test
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools` currently fails:
  `test_full_toolset_specs_for_gpt5_codex_unified_exec_web_search` needs
  its expected default tool list updated for `image_generation`

  Won Park · 2026-04-16 09:05:38 -07:00
  85203d8872
• Update ToolSearch to be enabled by default (#17854)

  ## Summary
  - Promote `Feature::ToolSearch` to `Stable` and enable it in the default
  feature set
  - Update feature tests and tool registry coverage to match the new
  default
  - Adjust the search-tool integration test to assert the default-on path
  and explicit disable fallback
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-features`
  - `cargo test -p codex-core --test all search_tool`
  - `cargo test -p codex-tools`

  Matthew Zeng · 2026-04-15 22:01:05 -07:00
  77fe33bf72
• [mcp] Add dummy tools for previously called but currently missing tools. (#17853)

  - [x] Add dummy tools for previously called but currently missing tools.
  Currently supporting MCP tools only.

  Matthew Zeng · 2026-04-15 21:48:05 +00:00
  28b76d13fe
• chore(features) codex dependencies feat (#17960)

  ## Summary
  Setting this up
  
  ## Testing
  - [x] Unit tests pass

  Dylan Hurd · 2026-04-15 10:59:59 -07:00
  652380d362
• [codex-analytics] enable general analytics by default (#17389)

  ## Summary
  - Make GeneralAnalytics stable and enabled by default.
  - Update feature tests and app-server lifecycle fixtures for explicit
  general_analytics=false.
  - Keep app-server integration tests isolated from host managed config so
  explicit feature fixtures are deterministic.
  
  ## Validation
  - cargo test -p codex-features
  - cargo test -p codex-app-server general_analytics (matched 0 tests)
  - cargo test -p codex-app-server thread_start_
  - cargo test -p codex-app-server thread_fork_
  - cargo test -p codex-app-server thread_resume_
  - cargo test -p codex-app-server
  config_read_includes_system_layer_and_overrides

  rhan-oai · 2026-04-14 13:20:46 -07:00
  d6b13276c7
• Keep image_detail_original as a removed feature flag (#17803)
  Curtis 'Fjord' Hawthorne · 2026-04-14 18:06:50 +00:00
  769b1c3d7e
• Always enable original image detail on supported models (#17665)

  ## Summary
  
  This PR removes `image_detail_original` as a runtime experiment and
  makes original image detail available whenever the selected model
  supports it.
  
  Concretely, this change:
  - drops the `image_detail_original` feature flag from the feature
  registry and generated config schema
  - makes tool-emitted image detail depend only on
  `ModelInfo.supports_image_detail_original`
  - updates `view_image` and `code_mode`/`js_repl` image emission to use
  that capability check directly
  - removes now-redundant experiment-specific tests and instruction
  coverage
  - keeps backward compatibility for existing configs by silently ignoring
  a stale `features.image_detail_original` entry
  
  The net effect is that `detail: "original"` is always available on
  supported models, without requiring an experiment toggle.

  Curtis 'Fjord' Hawthorne · 2026-04-14 08:15:56 -07:00
  f030ab62eb
• Add use_agent_identity feature flag (#17385)
  Adrian · 2026-04-11 09:52:06 -07:00
  39cc85310f
• Configure multi_agent_v2 spawn agent hints (#17071)

  Allow multi_agent_v2 features to have its own temporary configuration
  under `[features.multi_agent_v2]`
  
  ```
  [features.multi_agent_v2]
  enabled = true
  usage_hint_enabled = false
  usage_hint_text = "Custom delegation guidance."
  hide_spawn_agent_metadata = true
  ```
  
  Absent `usage_hint_text` means use the default hint.
  
  ```
  [features]
  multi_agent_v2 = true
  ```
  
  still works as the boolean shorthand.

  pakrym-oai · 2026-04-08 08:42:18 -07:00
  4c07dd4d25
• 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
• Promote image_detail_original to experimental (#16957)
  Curtis 'Fjord' Hawthorne · 2026-04-06 17:25:16 -07:00
  d2df7c54b2