6640 Commits

This Branch

This Branch

All Branches

• [codex] Allow empty turn/start requests (#23409)

  ## Why
  
  `turn/start` already accepts an input array on the wire, including an
  empty array, but core treated empty input as a no-op before the turn
  could reach the model. App-server clients need to be able to start a
  real turn even when there is no new user message, for example to let the
  model proceed from existing thread context.
  
  ## What changed
  
  - Removed the `run_turn` early return that skipped empty-input turns
  when there was no pending input.
  - Kept empty active-turn steering rejected by moving the `steer_input`
  empty-input check until after core has determined whether there is an
  active regular turn.
  - Empty regular turns now refresh `previous_turn_settings` like other
  regular turns, so follow-up context injection state advances
  consistently.
  - Added an app-server v2 integration test proving `turn/start` with
  `input: []` emits started/completed notifications, sends one Responses
  request, and does not synthesize an empty user message.
  
  ## Validation
  
  - `cargo test -p codex-app-server --test all
  turn_start_with_empty_input_runs_model_request`

  pakrym-oai · 2026-05-19 08:39:45 -07:00
  ef24ef127f
• Defer v1 multi-agent tools behind tool search (#23144)

  Summary: defer v1 multi-agent tools when tool_search and namespace tools
  are available; keep concise searchable descriptions and move the v1
  usage guidance into developer instructions; add targeted coverage.
  Testing: not run per request; ran just fmt.

  jif-oai · 2026-05-19 15:04:35 +02:00
  b3ae3de405
• 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
• Remove ToolsConfig from tool planning (#22835)

  ## Why
  
  `codex-tools` is meant to hold reusable tool primitives, but
  `ToolsConfig` had become a second copy of core runtime decisions instead
  of a small shared contract. It carried provider capabilities, auth/model
  gates, permission and environment state, web/search/image feature gates,
  multi-agent settings, and goal availability from core into `codex-tools`
  ([definition](https://github.com/openai/codex/blob/22dd9ad3929253ed24d7ee4f10f238e95ab25f37/codex-rs/tools/src/tool_config.rs#L97),
  [stored on each
  `TurnContext`](https://github.com/openai/codex/blob/22dd9ad3929253ed24d7ee4f10f238e95ab25f37/codex-rs/core/src/session/turn_context.rs#L87)).
  Every session/context variant then had to build and mutate that snapshot
  before assembling tools.
  
  This PR removes that master object instead of renaming it. Tool planning
  now reads the live `TurnContext`, where `codex-core` already owns those
  decisions, while `codex-tools` keeps only reusable primitives and a
  generic `ToolSetBuilder`/`ToolSet` accumulator.
  
  ## What Changed
  
  - Removed `ToolsConfig` / `ToolsConfigParams` from `codex-tools`; the
  crate keeps the shared helpers that still belong there, including
  request-user-input mode selection, shell backend/type resolution,
  `UnifiedExecShellMode`, and `ToolEnvironmentMode`.
  - Replaced config-snapshot planning with `ToolRouter::from_turn_context`
  and a `spec_plan` pipeline over `CoreToolPlanContext`, deriving provider
  capabilities, auth gates, model support, feature gates, environment
  count, goal support, multi-agent options, web search, and image
  generation from the authoritative turn state.
  - Added generic `codex_tools::ToolSetBuilder` / `ToolSet`, plus the
  small core adapter needed to accumulate `CoreToolRuntime` values and
  hosted model specs.
  - Added the `tool_family::shell` registration module and moved
  shell/unified-exec/memory accounting call sites to read the narrow
  per-turn fields directly.
  - Narrowed `TurnContext` to the remaining explicit per-turn fields
  needed by planning: `available_models`, `unified_exec_shell_mode`, and
  `goal_tools_supported`.
  - Reworked MCP exposure and tool-search setup so deferred/direct MCP
  behavior is driven by the current turn rather than a precomputed config
  snapshot.
  - Replaced the large expected-spec fixture tests with focused
  behavior-level coverage for shell tools, environments, goal and
  agent-job gates, MCP direct/deferred exposure, tool search,
  request-plugin-install, code mode, multi-agent mode, hosted tools, and
  extension executor dispatch.
  
  ## Verification
  
  - `cargo check -p codex-tools`
  - `cargo check -p codex-core --lib`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core spec_plan --lib`
  - `cargo test -p codex-core router --lib`

  jif-oai · 2026-05-19 11:24:09 +02:00
  05e171094d
• feat: dedicated goal DB (#23300)

  ## Why
  
  Thread goals are moving toward extension-owned runtime behavior, but
  their persisted state was still stored in the shared state database.
  This makes the goal store harder to isolate and keeps future storage
  splits tied to ad hoc runtime plumbing.
  
  This PR gives goals their own SQLite database while keeping the existing
  `StateRuntime` entry point. The goal is to make this the pattern for
  adding more dedicated runtime databases later.
  
  This also reduce load on existing DB and reduce contention
  
  ## Limitation
  Thread preview from goal is not supported anymore. I'm looking into this
  [EDIT]: solved
  
  ## What changed
  
  - Added a dedicated `goals_1.sqlite` database with its own
  `goals_migrations` directory.
  - Moved `thread_goals` creation into the goals DB migration set.
  - Dropped the old `thread_goals` table from the main state DB with a
  normal state migration. There is intentionally no backfill for existing
  goal rows.
  - Changed `GoalStore` to be backed only by the goals DB pool.
  - Removed the old goal-write side effect that filled empty
  `threads.preview` values from the goal objective.
  - Added shared runtime DB path metadata so startup, telemetry, `codex
  doctor`, and repair handling can include future DBs without bespoke path
  lists.
  - Updated Bazel compile data so the new goals migration directory is
  available to `sqlx::migrate!`.
  
  ## Verification
  
  - `cargo check --tests -p codex-state -p codex-cli -p codex-core -p
  codex-app-server`
  - `just fix -p codex-state`
  - `just fix -p codex-cli`
  - `just fix -p codex-app-server`

  jif-oai · 2026-05-19 11:11:41 +02:00
  ba57aab13a
• Preserve context baselines for full-history agent forks (#23352)

  ## Why
  
  Full-history agent forks should continue from the same prompt prefix as
  the parent. Dropping the stored `TurnContext` baseline forced the child
  to rebuild startup context on its first turn, which can duplicate
  developer instructions and also loses the cache continuity that a
  full-history fork is supposed to preserve.
  
  Truncated forks are different: once we keep only the last N turns, the
  original prompt prefix is no longer intact, so the child must establish
  a fresh context baseline.
  
  ## What changed
  
  - Preserve `RolloutItem::TurnContext` when forking with
  `SpawnAgentForkMode::FullHistory`, and keep dropping it for truncated
  forks:
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control.rs#L98-L126
  and
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control.rs#L399-L401
  - Remove the special-case MultiAgentV2 usage-hint filtering path.
  Full-history fork now preserves the cached developer prefix instead of
  trying to reconstruct part of it.
  - Extend the fork coverage to assert both sides of the contract:
  full-history forks keep the parent reference baseline, while last-N
  forks rebuild context after truncation:
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control_tests.rs#L603-L759
  and
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control_tests.rs#L854-L977
  
  ## Verification
  
  - `cargo test -p codex-core
  spawn_agent_can_fork_parent_thread_history_with_sanitized_items --
  --nocapture`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core
  spawn_agent_fork_last_n_turns_keeps_only_recent_turns -- --nocapture`

  jif-oai · 2026-05-19 10:34:24 +02:00
  826b2182ed
• 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
• Remove explicit connector tool undeferral (#23390)

  ## Summary
  - remove the explicit-connector carveout that kept mentioned app tools
  directly exposed instead of deferred
  - keep the surviving explicit-mention reconstruction only for analytics,
  preserving `codex_app_mentioned` and `codex_app_used.invoke_type`
  - trim the now-unused prompt/tool-exposure plumbing and refresh coverage
  around always-defer behavior
  
  ## Verification
  - `just fmt`
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-core` *(one transient timeout in
  `shell_snapshot::tests::macos_zsh_snapshot_includes_sections`; isolated
  rerun passed)*
  - `cargo test -p codex-core --lib
  shell_snapshot::tests::macos_zsh_snapshot_includes_sections`
  - `cargo test -p codex-core --test all
  explicit_app_mentions_respect_always_defer`
  - `cargo test -p codex-core --lib
  mcp_tool_exposure::tests::always_defer_feature_defers_apps_too`
  - `just fix -p codex-analytics`
  - `just fix -p codex-core`

  sayan-oai · 2026-05-18 21:33:46 -07:00
  1dd9bf9a74
• CI: Customize v8 building (#22086)

  ## Summary
  
  Move the rusty_v8 artifact production into hermetic Bazel path and bump
  the `v8` crate to `147.4.0`
  
  The new flow builds V8 release artifacts from source for Darwin and
  Linux targets, publishes both the current release-compatible artifacts
  and sandbox-enabled variants, and keeps Cargo consumers on prebuilt
  binaries by continuing to feed the `v8` crate the archive and generated
  binding files it already expects.
  
  ## Why
  
  We need control over V8 build-time features without giving up prebuilt
  artifacts for downstream Cargo builds.
  
  Upstream `rusty_v8` already supports source-only features such as
  `v8_enable_sandbox`, but its normal prebuilt release assets do not cover
  every feature combination we need. Building the artifacts ourselves lets
  us enable settings such as the V8 sandbox and pointer compression at
  artifact build time, then publish those outputs so ordinary Cargo builds
  can still consume prebuilts instead of compiling V8 locally.
  
  This keeps the fast consumer experience of prebuilt `rusty_v8` archives
  while giving us a reproducible path to ship featureful variants that
  upstream does not currently publish for us.
  
  ## Implementation Notes
  
  The Bazel graph in this PR is not copied wholesale from `rusty_v8`;
  `rusty_v8`'s normal source build is still GN/Ninja-based.
  
  Instead, this change starts from upstream V8's Bazel rules and adapts
  them to Codex's hermetic toolchains and dependency layout. Where we
  intentionally follow `rusty_v8`, we mirror its existing artifact
  contract:
  
  - the same `v8` crate version and generated binding expectations
  - the same sandbox feature relationship, where sandboxing requires
  pointer compression
  - the same custom libc++ model expected by Cargo's default
  `use_custom_libcxx` feature
  - the same release-style archive plus `src_binding` outputs consumed by
  the `v8` crate
  
  To preserve that contract, the Bazel release path pins the libc++,
  libc++abi, and llvm-libc revisions used by `rusty_v8 v147.4.0`, builds
  release artifacts with `--config=rusty-v8-upstream-libcxx`, and folds
  the matching runtime objects into the final static archive.
  
  ## Windows
  
  Windows is annoyingly handled differently.
  
  Codex's current hermetic Bazel Windows C++ platform is `windows-gnullvm`
  / `x86_64-w64-windows-gnu`, while upstream `rusty_v8` publishes Windows
  prebuilts for `*-pc-windows-msvc`. Those are different ABIs, so the
  Bazel graph cannot truthfully reproduce the upstream MSVC artifacts
  until we add a real MSVC-targeting C++ toolchain.
  
  For now:
  
  - Windows MSVC consumers continue to use upstream `rusty_v8` release
  archives.
  - Windows GNU targets are built in-tree so they link against a matching
  GNU ABI.
  - The canary workflow separately exercises upstream `rusty_v8` source
  builds for MSVC sandbox artifacts, but MSVC is not yet part of the
  Bazel-produced release matrix.
  
  ## Validation
  This PR is technically self validating through CI. I have already
  published it as a release tag so the artifacts from this branch are
  published to
  https://github.com/openai/codex/releases/tag/rusty-v8-v147.4.0 CI for
  this PR should therefore consume our own release targets. I have also
  locally tested for linux and darwin.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Channing Conger · 2026-05-18 21:33:05 -07:00
  7cdeab33d1
• [5 of 7] Replace OverrideTurnContext with ThreadSettings (#22508)

  **Stack position:** [5 of 7]
  
  ## Summary
  
  This PR adds `Op::ThreadSettings`, a queued settings-only update
  mechanism for changing stored thread settings without starting a new
  turn. It also removes the legacy `Op::OverrideTurnContext` in the same
  layer, so reviewers can see the replacement and deletion together.
  
  ## Changes
  
  - Add `Op::ThreadSettings` for settings-only queued updates.
  - Emit `ThreadSettingsApplied` with the effective thread settings
  snapshot after core applies an update.
  - Route settings-only updates through the same submission queue as user
  input.
  - Migrate remaining `OverrideTurnContext` tests and callers to the
  queued `Op::ThreadSettings` path.
  - Delete `Op::OverrideTurnContext` from the core protocol and submission
  loop.
  
  This stack addresses #20656 and #22090.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508) (this PR)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 21:03:51 -07:00
  a668379abf
• fix(plugins): keep version upgrades additive (#23356)

  ## Why
  
  Windows can reject plugin cache upgrades when a running MCP server still
  has its working directory inside the currently active plugin version.
  The existing cache refresh path replaces
  `plugins/cache/<marketplace>/<plugin>` as a whole, so a live handle
  under the old version can make an otherwise ordinary version bump fail.
  
  This PR keeps the existing plugin-selection model intact while making
  version bumps less disruptive.
  
  ## What changed
  
  - When installing a new version beside an existing plugin cache root,
  move only the staged version directory into place instead of replacing
  the whole plugin root.
  - Best-effort prune older sibling version directories after the new
  version is activated.
  - Preserve the existing whole-root replacement path for first installs
  and same-version refreshes.
  - Add regression coverage for upgrading from `1.0.0` to `2.0.0` without
  replacing the plugin root.
  
  ## Verification
  
  - `cargo test -p codex-core-plugins install_with_new_version`
  - `cargo fmt --package codex-core-plugins --check`

  iceweasel-oai · 2026-05-19 04:02:30 +00:00
  d3d38159ed
• [codex] Extract turn skill and plugin injections (#23396)

  ## Why
  
  `run_turn` had accumulated the turn-scoped skill, plugin, app, MCP,
  connector-selection, and analytics setup inline. That made the
  orchestration path harder to scan even though the actual turn item
  injection still needs to stay in `run_turn` so ordering is explicit.
  
  ## What changed
  
  This extracts that setup into `build_skills_and_plugins`, which returns
  the combined injection `ResponseItem`s and the explicitly enabled
  connector IDs. `run_turn` now keeps the required orchestration pieces:
  context update recording, user input handling, connector selection
  merge, and the explicit per-item `record_conversation_items` calls for
  injection items.
  
  The refactor keeps the change LOC-neutral in `core/src/session/turn.rs`
  and preserves the existing response-item based injection path.
  
  ## Validation
  
  - `cargo test -p codex-core collect_explicit_app_ids_from_skill_items`
  - `just fix -p codex-core`

  pakrym-oai · 2026-05-18 20:33:27 -07:00
  9e9a62dc28
• [3 of 7] Remove UserTurn (#23075)

  **Stack position:** [3 of 7]
  
  ## Summary
  
  This PR finishes the input-op consolidation by moving the remaining
  `Op::UserTurn` callers onto `Op::UserInput` and deleting `Op::UserTurn`.
  This touches a lot of files, but it is a low-risk mechanical migration.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075) (this PR)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 19:56:00 -07:00
  1a25d8b6e5
• [2 of 7] Remove UserInputWithTurnContext (#23081)

  **Stack position:** [2 of 7]
  
  ## Summary
  
  This PR removes the overlapping `Op::UserInputWithTurnContext` variant
  now that `Op::UserInput` can carry thread settings overrides directly.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  (this PR)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 19:41:33 -07:00
  e811234484
• [1 of 7] Add thread settings to UserInput (#23080)

  **Stack position:** [1 of 7]
  
  ## Summary
  
  The first three PRs in this stack are a cleanup pass before the actual
  thread settings API work.
  
  Today, core has several overlapping "user input" ops: `UserInput`,
  `UserInputWithTurnContext`, and `UserTurn`. They differ mostly in how
  much next-turn state they carry, which makes the later queued thread
  settings update harder to reason about and review.
  
  This PR starts that cleanup by adding the shared
  `ThreadSettingsOverrides` payload and allowing `Op::UserInput` to carry
  it. Existing variants remain in place here, so this layer is mostly a
  behavior-preserving API shape change plus mechanical constructor
  updates.
  
  ## End State After PR3
  
  By the end of PR3, `Op::UserInput` is the only "user input" core op. It
  can carry optional thread settings overrides for callers that need to
  update stored defaults with a turn, while callers without updates use
  empty settings. `Op::UserInputWithTurnContext` and `Op::UserTurn` are
  deleted.
  
  ## End State After PR5
  
  By the end of PR5, core will have only two ops for this area:
  
  - `Op::UserInput` for user-input-bearing submissions.
  - `Op::ThreadSettings` for settings-only updates.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080) (this PR)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 18:48:35 -07:00
  84d941d07f
• 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
• cleanup: Remove skill env var dependency prompting (#22721)

  Deletes the skill env var dependency prompt feature and its runtime
  path. env_var entries in skill dependency metadata are now silently
  ignored during skill loading.

  xl-openai · 2026-05-19 01:24:19 +00:00
  6b54ced108
• [codex] Remove external websocket session resets (#23384)

  ## Why
  
  Compaction now installs replacement history inside the session, but the
  turn and compaction callers were still reaching into
  `ModelClientSession` to reset websocket transport state after that
  install. That made a transport-level reset part of the compaction API
  even though websocket incremental request selection already checks
  whether the next request is a strict extension of the previous one and
  falls back to a full `response.create` when it is not.
  
  ## What changed
  
  - Removed the compaction-side calls to `reset_websocket_session` from
  `compact.rs` and `session/turn.rs`.
  - Simplified pre-sampling and mid-turn compaction helpers so they return
  `CodexResult<()>` instead of carrying a reset flag.
  - Made `ModelClientSession::reset_websocket_session` private to
  `client.rs`, leaving only the websocket timeout recovery path inside the
  client as a caller.
  
  ## Validation
  
  - `cargo test -p codex-core --test all
  responses_websocket_creates_on_non_prefix`
  - `cargo test -p codex-core --test all
  steered_user_input_waits_for_model_continuation_after_mid_turn_compact`
  - `cargo test -p codex-core --test all
  pre_sampling_compact_runs_on_switch_to_smaller_context_model`

  pakrym-oai · 2026-05-19 01:13:38 +00:00
  17d552fb4d
• app-server: use profile ids in v2 permission params (#23360)

  ## Why
  
  The v2 app-server permission profile fields are experimental, but the
  previous migration kept a legacy object payload for profile selection.
  That made clients aware of server-owned `activePermissionProfile`
  metadata such as `extends`, and it kept a
  `legacy_additional_writable_roots` path even though
  `runtimeWorkspaceRoots` now owns runtime workspace-root selection.
  
  This PR makes the client contract match the intended model: clients
  select a permission profile by id, and the server resolves and reports
  active profile provenance in response payloads.
  
  Follow-up to #22611.
  
  ## What Changed
  
  - Changed `thread/start`, `thread/resume`, `thread/fork`, and
  `turn/start` permission profile selection to plain profile id strings.
  - Changed `command/exec.permissionProfile` to a plain profile id string
  for the same client/server ownership split.
  - Removed `PermissionProfileSelectionParams` and the legacy `{ type:
  "profile", modifications: [...] }` compatibility deserializer.
  - Updated app-server, TUI, and `codex exec` call sites to send only ids,
  while keeping `activePermissionProfile` as server response metadata.
  - Updated app-server docs and schema fixtures for the revised
  `command/exec.permissionProfile` shape.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-app-server`
  - `cargo test -p codex-exec`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-tui`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23360).
  * #23368
  * __->__ #23360

  Michael Bolin · 2026-05-18 17:28:50 -07:00
  3fd79b7986
• [codex-analytics] preserve user thread source for exec threads (#23376)

  ## Why
  - Follows #20949.
  - The above moved `thread_source` attribution from the reducer to
  explicit caller provided metadata
  - The `codex exec` path still omitted this metadata, leaving
  exec-created threads without `thread_source`
  
  
  ## What Changed
  - Ensures exec threads are marked as user created (`thread_source =
  "user"`)
  - Preserves thread-source metadata in exec’s startup session event
  
  
  ## Verification
  - Updated unit tests to validate exec `thread_source` propagation.
  - `cargo +1.93.0 test -p codex-exec --manifest-path codex-rs/Cargo.toml`
  - `cargo +1.93.1 build -p codex-cli --manifest-path codex-rs/Cargo.toml`
  - Validated locally with a freshly built `codex exec` run:
    - Startup logs showed `thread_source: Some(User)`.
    - Rollout metadata recorded `"thread_source":"user"`.

  marksteinbrick-oai · 2026-05-18 17:13:49 -07:00
  5696167fe8
• fix(tui): warn on unsupported iTerm2 pet versions (#23371)

  ## Why
  
  Older iTerm2 builds can be detected as supporting the image transport
  that terminal pets use, but in practice they fail to render the pet flow
  correctly. Instead of silently attempting image rendering, Codex should
  tell the user that their iTerm2 version is too old and that upgrading is
  the fix.
  
  ## What Changed
  
  - gate iTerm2 pet auto-detection on version `3.6.0` or newer
  - show a dedicated upgrade message for older or unknown iTerm2 versions
  instead of the generic unsupported-terminal warning
  - keep the existing generic unsupported-terminal path for non-iTerm
  terminals
  - add regression coverage for iTerm2 version parsing and the old-iTerm
  warning path
  
  ## How to Test
  
  1. Start Codex in iTerm2 3.6 or newer.
  2. Run `/pets`.
  3. Confirm the pets picker opens instead of showing a warning.
  4. Start Codex in an older iTerm2 build, or exercise the equivalent test
  path.
  5. Run `/pets`.
  6. Confirm Codex warns that pets require iTerm2 3.6 or newer and tells
  the user to upgrade.
  7. Also verify that a non-iTerm unsupported terminal still shows the
  generic unsupported-terminal message.
  
  Targeted tests:
  - `cargo test -p codex-terminal-detection`
  - `cargo test -p codex-tui pets::`
  - `cargo test -p codex-tui slash_pets_on_unsupported_terminal`
  - `cargo test -p codex-tui slash_pets_on_old_iterm2`

  Felipe Coury · 2026-05-18 20:24:09 -03:00
  a66712c95d
• [codex] Move pending input into input queue (#22728)

  ## Why
  
  Pending model input was split across `Session`, `TurnState`, and the
  agent mailbox. That made it easy for new paths to manage queued user
  input or mailbox delivery outside the intended ownership boundary.
  
  This PR consolidates the model-facing input lifecycle behind the session
  input queue so turn-local pending input, next-turn queued items, and
  mailbox delivery coordination are owned in one place.
  
  ## What Changed
  
  - Added `session/input_queue.rs` to own pending input queues and mailbox
  delivery coordination.
  - Removed the standalone `agent/mailbox.rs` channel wrapper and store
  mailbox items directly in the input queue.
  - Moved pending-input mutations off `TurnState`; `TurnState` now exposes
  the queue-owned storage directly for now.
  - Routed abort cleanup, mailbox delivery phase changes, next-turn queued
  items, and active-turn pending input through `InputQueue`.
  - Boxed stack-heavy agent resume/fork startup futures that the refactor
  pushed over the default test stack.
  - Updated session, task, goal, stream-event, and multi-agent call sites
  and tests to use the new queue ownership.
  
  ## Verification
  
  - `cargo test -p codex-core --lib agent::control::tests`
  - `cargo test -p codex-core --lib
  agent::control::tests::resume_closed_child_reopens_open_descendants --
  --exact`
  - `cargo test -p codex-core --lib
  agent::control::tests::spawn_agent_fork_last_n_turns_keeps_only_recent_turns
  -- --exact`
  - `cargo test -p codex-core --lib
  agent::control::tests::resume_thread_subagent_restores_stored_nickname_and_role
  -- --exact`
  - `cargo test -p codex-core` was also run; it completed with 1814
  passed, 4 ignored, and one timeout in
  `agent::control::tests::resume_thread_subagent_restores_stored_nickname_and_role`,
  which passed when rerun in isolation.

  pakrym-oai · 2026-05-18 15:43:01 -07:00
  afa0101ae2
• 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] Trim unused TurnContextItem fields (#22709)

  ## Why
  
  `TurnContextItem` is the durable baseline used to reconstruct context
  diffs across resume/fork. Most of the old persisted-only fields on it
  are no longer read, so keeping them in rollout snapshots adds schema
  surface and state that can drift without affecting reconstruction.
  
  `summary` is the exception: older Codex versions require it to
  deserialize `turn_context` records, so keep writing a default
  compatibility value until that schema surface can be removed safely.
  
  ## What changed
  
  - Removed the unused persisted fields from `TurnContextItem`: trace ids,
  user/developer instructions, output schema, and truncation policy.
  - Kept `summary` with a compatibility comment and made
  `TurnContext::to_turn_context_item` write `ReasoningSummary::Auto`
  instead of live turn state.
  - Updated rollout/context reconstruction fixtures for the retained
  summary field.
  
  ## Verification
  
  - `cargo test -p codex-protocol --lib turn_context_item`
  - `cargo test -p codex-rollout
  resume_candidate_matches_cwd_reads_latest_turn_context`
  - `cargo test -p codex-state turn_context`
  - `cargo test -p codex-core --lib
  new_default_turn_captures_current_span_trace_id`
  - `cargo test -p codex-core --lib
  record_initial_history_resumed_turn_context_after_compaction_reestablishes_reference_context_item`
  - `cargo test -p codex-core --test all
  emits_warning_when_resumed_model_differs`
  - `git diff --check`

  pakrym-oai · 2026-05-18 21:54:36 +00:00
  f2368b7de6
• Publish Linux runtime wheels with glibc-compatible tags (#21812)

  ## Why
  
  The Python SDK depends on `openai-codex-cli-bin` runtime wheels being
  installable on the Linux hosts our users actually run. The release
  workflow currently tags the Linux runtime artifacts as `musllinux_*`,
  which makes pip ignore them on normal glibc distributions even though
  the bundled Rust executables are intended to run there.
  
  ## What changed
  
  - Tag the Linux runtime wheels as `manylinux_2_17_aarch64` and
  `manylinux_2_17_x86_64` instead of `musllinux_1_1_*`.
  - Keep the existing runtime wheel build and publish flow unchanged
  otherwise.
  
  ## Verification
  
  - Confirmed the wheel-tag issue against the PyPA platform-tag rules for
  `manylinux` vs `musllinux`.
  - This PR is now intentionally scoped to the tag correction only; the
  broader Python runtime release workflow has already landed on `main`
  through the merged stack.
  
  ## Follow-up
  
  After publishing the next alpha from this branch, install the
  SDK/runtime in a fresh glibc Linux environment and confirm pip resolves
  the tagged Linux wheel as expected.
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-18 14:09:25 -07:00
  c95a70fb42
• Improve codex remote-control CLI UX (#22878)

  ## Description
  
  This PR makes `codex remote-control` behave like a foreground CLI
  command by default. Running it now starts remote control, waits for
  readiness, prints a clear status message with the machine name, and
  stays alive until Ctrl-C.
  
  Users who want daemon behavior can use `codex remote-control start`, and
  `codex remote-control stop` now prints concise human-readable output.
  `--json` remains available for scripts.
  
  Implementation-wise, this now verifies the real app-server state instead
  of just assuming startup worked. The CLI starts or connects to
  app-server, probes its control socket, calls the `remoteControl/enable`
  API, and waits for the remote-control status response/notification
  before printing success.
  
  For daemon mode, `codex remote-control start` also reports which managed
  app-server binary was used, including its path and best-effort `codex
  --version`, so failures are easier to diagnose.
  
  ## Examples
  
  Example output:
  ```
  > codex remote-control
  Starting app-server with remote control enabled...
  This machine is available for remote control as com-97826.
  Press Ctrl-C to stop.
  ```
  
  Error case using daemon (currently expected based on our publicly
  released CLI version):
  ```
  > ./target/debug/codex remote-control start
  Starting app-server daemon with remote control enabled...
  Error: app server did not become ready on /Users/owen/.codex/app-server-control/app-server-control.sock
  
  Daemon used app-server:
    path: /Users/owen/.codex/packages/standalone/current/codex
    version: 0.130.0
  
  Managed app-server stderr (/Users/owen/.codex/app-server-daemon/app-server.stderr.log):
    error: unexpected argument '--remote-control' found
    
    Usage: codex app-server [OPTIONS] [COMMAND]
    
    For more information, try '--help'.
  
  Caused by:
      0: failed to connect to /Users/owen/.codex/app-server-control/app-server-control.sock
      1: No such file or directory (os error 2)
  ```
  
  ## What changed
  
  - `codex remote-control` now runs remote control in the foreground and
  prints a Ctrl-C stop hint.
  - `codex remote-control start` starts the daemon and waits for remote
  control readiness before reporting success.
  - `codex remote-control stop` reports stopped/not-running status in
  plain language.
  - Startup failures now include recent managed app-server stderr to make
  daemon issues easier to diagnose.
  - Added coverage for CLI output, readiness waiting, foreground shutdown,
  and stderr log tailing.

  Owen Lin · 2026-05-18 13:39:02 -07:00
  1752f374a8
• Reduce rust-ci-full Windows nextest timeout flakes (#23253)

  ## Why
  Recent `rust-ci-full` failures were dominated by transient Windows
  timeout clusters in process-heavy tests such as `suite::resume`,
  `suite::cli_stream`, `suite::auth_env`,
  `start_thread_uses_all_default_environments_from_codex_home`, and
  `connect_stdio_command_initializes_json_rpc_client_on_windows`.
  
  The goal here is to make those known flaky paths less likely to fail
  full CI without relaxing the global nextest timeout policy.
  
  ## What changed
  - Enable one global nextest retry with `retries = 1` so a single
  transient failure can recover.
  - Add a `windows_process_heavy` test group with `max-threads = 2` for
  the recurring Windows subprocess/session-heavy timeout families.
  - Add Windows-only slow-timeout overrides for that process-heavy group.
  - Add a narrower Windows-only timeout override for
  `start_thread_uses_all_default_environments_from_codex_home`, which
  still exceeded the broader Windows bucket in both Windows full-CI lanes.
  - Increase the `rust-ci-full` nextest job timeout from `45m` to `60m` so
  Windows ARM64 still has job-level headroom after retries and targeted
  per-test timeout increases.
  - Keep the global `slow-timeout` unchanged at `15s`.
  
  ## Validation
  Validated through `rust-ci-full` GitHub Actions reruns on this PR.
  
  Observed improvement on the tuned Windows lanes:
  - Windows x64 went from `5 timed out` to `0 timed out`.
  - Windows ARM64 went from `2 timed out` to `0 timed out`.
  - `start_thread_uses_all_default_environments_from_codex_home` recovered
  as a flaky pass on Windows ARM64 instead of timing out.
  
  The remaining failing tests in those runs were unrelated hard failures
  outside this nextest timeout tuning.

  starr-openai · 2026-05-18 13:06:39 -07:00
  732b12b1ef
• Add tool lifecycle extension contributor (#23309)

  ## Why
  
  Extensions that need to track runtime progress currently have no typed
  host signal for tool execution. The goal extension in particular needs
  to observe tool attempts without inspecting tool payloads, owning tool
  implementations, or staying coupled to core-only runtime plumbing.
  
  This adds a narrow lifecycle contributor API for host-owned tool
  execution: extensions can observe when an accepted tool call starts and
  how it finishes, while policy hooks and tool handlers continue to own
  payload rewriting, blocking, and execution.
  
  Relevant code:
  
  -
  [`ToolLifecycleContributor`](https://github.com/openai/codex/blob/3ad2850ffc7d8a1da19c65a92425637a59098f1b/codex-rs/ext/extension-api/src/contributors.rs#L119)
  defines the extension-facing observer contract.
  -
  [`tool_lifecycle.rs`](https://github.com/openai/codex/blob/3ad2850ffc7d8a1da19c65a92425637a59098f1b/codex-rs/ext/extension-api/src/contributors/tool_lifecycle.rs)
  defines the typed start/finish inputs, source, and outcome enums.
  - [`notify_tool_start` /
  `notify_tool_finish`](https://github.com/openai/codex/blob/3ad2850ffc7d8a1da19c65a92425637a59098f1b/codex-rs/core/src/tools/lifecycle.rs)
  bridges core tool dispatch into the extension registry.
  
  ## What Changed
  
  - Added `ToolLifecycleContributor` to `codex-extension-api`, including:
    - `ToolStartInput`
    - `ToolFinishInput`
    - `ToolCallSource`
    - `ToolCallOutcome`
  - Added registration and lookup support on `ExtensionRegistryBuilder` /
  `ExtensionRegistry`.
  - Wired core tool dispatch to notify lifecycle contributors for:
    - accepted tool starts
    - completed tool calls, including the tool output success marker
    - pre-tool-use blocks
    - failures before or after the handler runs
    - cancellation/abort in the parallel tool path
  - Registered the goal extension as a lifecycle contributor and added the
  outcome filter it will use for goal progress accounting.
  
  ## Test Coverage
  
  - Added `dispatch_notifies_tool_lifecycle_contributors` to cover
  lifecycle notification ordering and outcomes for successful and
  handler-failed tool calls.

  jif-oai · 2026-05-18 21:55:57 +02:00
  c69cde3547
• fix: default unknown tool schemas to empty schemas (#22380)

  ## Why
  
  Some tool providers, especially MCP servers and dynamic tool sources,
  can supply schema nodes that omit `type` and have no recognized JSON
  Schema shape hints. Previously, `sanitize_json_schema` filled those
  unknown nodes in as `string`, which made the schema parseable but
  invented a scalar constraint that the provider did not specify. For
  description-only fields, that could incorrectly steer tool arguments
  away from the provider's actual accepted shape.
  
  The Responses API accepts permissive empty schemas such as `{}` at
  nested property positions, so Codex should preserve that permissive
  meaning instead of coercing unknown schema nodes into a misleading
  scalar type.
  
  ## What Changed
  
  - Changed the no-hints fallback in `codex-rs/tools/src/json_schema.rs`
  to clear unrecognized object schema nodes to `{}`.
  - Empty schemas now remain `{}` rather than becoming `type: "string"`.
  - Description-only or otherwise metadata-only nested property schemas
  now become `{}` while surrounding object/array/string/number inference
  still applies when recognized hints are present.
  - Updated `codex-tools` and `codex-core` tests to cover top-level empty
  schemas, nested empty schemas, metadata-only malformed schemas, dynamic
  tools, and MCP tool specs.
  
  ## Verification
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core
  test_mcp_tool_property_missing_type_defaults_to_empty_schema`
  - Manually verified the real Responses API behavior for both
  empty-schema positions:
  - Top-level function `parameters: {}` is accepted and echoed back as
  `{"type":"object","properties":{}}`; when forced to call the tool,
  Responses emitted empty object arguments: `"arguments": "{}"`.
  - Nested property schema `{}` is accepted and preserved as `{}`; when
  forced to call a tool with `metadata.extra`, Responses emitted
  `"arguments": "{\"metadata\":{\"extra\":\"codex schema sanitizer
  behavior\"}}"`.

  Celia Chen · 2026-05-18 12:41:10 -07:00
  4dbca61e20
• 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
• feat(app-server): add optional thread_id to experimentalFeature/list (#23335)

  ## Why
  
  `experimentalFeature/list` reports effective feature enablement, but
  currently does not resolve it against a working directory where
  project-local config.toml files can exist and toggle on/off features
  when merged into the effective config after resolving the various config
  layers. That means we effectively (and incorrectly) ignore features set
  in project-local config.
  
  To address that, this PR exposes an optional `thread_id` param which
  allows us to load the thread's `cwd.
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server experimental_feature_list`

  Owen Lin · 2026-05-18 12:12:14 -07:00
  139365a4bb
• feat(tui): handle paste in session picker (#23338)

  ## Why
  
  The session picker already supports typed search, but it ignored
  bracketed paste events entirely. On macOS terminals this makes pasted
  text look like a no-op on the resume screen, which is especially
  noticeable when a user wants to paste part of a thread name, branch, or
  path into the search field.
  
  ## What Changed
  
  - route `TuiEvent::Paste(String)` into the session picker instead of
  dropping it
  - normalize pasted search text into a single-line query by collapsing
  whitespace
  - ignore whitespace-only pastes
  - reuse the existing `set_query(...)` path so pasted searches keep the
  same filtering and pagination behavior as typed input
  - add focused tests for append behavior, whitespace normalization,
  whitespace-only paste, and the existing search-loading path
  
  This PR is stacked on top of #23234 and contains only the net change
  relative to `etraut/clarify-resume-hints`.
  
  ## How to Test
  
  1. Start Codex in a terminal that emits bracketed paste, for example
  iTerm2 on macOS.
  2. Open the resume picker so the search UI is visible.
  3. Copy a term that should match one of the visible sessions, then paste
  it into the picker.
  4. Confirm the query updates immediately and the list filters as if the
  text had been typed.
  5. Also verify that pasting text with newlines or tabs still produces a
  usable single-line search query.
  6. Also verify that normal typed search still works and that `Esc` still
  clears the query / exits as before.
  
  Targeted tests:
  - `cargo test -p codex-tui`
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Felipe Coury · 2026-05-18 19:04:41 +00:00
  8e52578e66
• goals: keep pause transitions explicit (#23088)

  ## Problem
  
  This addresses several user-reported cases where active goals were
  paused even though the user had not explicitly asked for that
  transition:
  
  - the guardian approval-review circuit breaker interrupted a turn and
  implicitly paused the goal
  - a shutdown in one app-server instance could pause a goal while a
  second instance was still actively running the same thread
  - steering-style interrupts could also pause the goal even though they
  are meant to redirect work, not stop the goal lifecycle
  
  The common problem was that core treated `TurnAbortReason::Interrupted`
  as an implicit request to transition the persisted goal to `paused`.
  That made unrelated interrupt paths mutate goal state as a side effect,
  and in the multi-app-server case it allowed stale process teardown to
  pause a live goal owned by another running client.
  
  After this change, transitioning a goal to `paused` is always an
  explicit action performed by a client or another intentional goal-state
  mutation. It is never an implicit transition triggered by generic
  interrupt handling.
  
  Refs #22884.
  
  ## What changed
  
  - Remove the goal runtime path that paused active goals after
  interrupted task aborts.
  - Drop the now-unused abort reason from `GoalRuntimeEvent::TaskAborted`.
  - Update the focused regression coverage so an interrupted active goal
  still accounts usage but remains `active`.

  Eric Traut · 2026-05-18 11:58:40 -07:00
  55f6bbc667
• TUI: replay in-progress MCP calls as started (#23236)

  Fixes #22300.
  
  ## Summary
  MCP tool calls can appear in thread history while still in progress.
  During replay, `handle_thread_item` routed every
  `ThreadItem::McpToolCall` to the completion handler, so an in-progress
  item with no result or error was rendered as `MCP tool call completed
  without a result`.
  
  This updates replay handling to mirror command executions: `InProgress`
  MCP calls go through `on_mcp_tool_call_started`, while completed and
  failed calls continue through the completion path.
  
  ## Validation
  - `cargo test -p codex-tui
  replayed_in_progress_mcp_tool_call_stays_active`

  Eric Traut · 2026-05-18 11:34:31 -07:00
  ae03d073b3
• TUI: route elicitation responses to request thread (#23241)

  ## Why
  
  Fixes #21894.
  
  When the TUI handles an MCP elicitation, the request payload already
  includes the thread that generated the elicitation.
  `ChatWidget::handle_elicitation_request_now` was ignoring that value and
  using the currently visible chat thread instead. In a multi-session TUI,
  that can send `resolve_elicitation` to an older visible thread rather
  than the session that owns the pending elicitation, producing
  `elicitation request not found` and leaving the prompt unresolved.
  
  ## What changed
  
  - Parse `McpServerElicitationRequestParams.thread_id` in the ChatWidget
  elicitation handler and use it for app-link, form, fallback approval,
  and auto-decline resolution paths.
  - Keep the existing visible-thread fallback only for malformed request
  payloads with an invalid thread id.
  - Update the invalid URL elicitation regression test so the visible
  thread and request thread intentionally differ.

  Eric Traut · 2026-05-18 11:33:13 -07:00
  53a1f4c29e
• Clarify resume hints for renamed threads (#23234)

  Addresses #23181
  
  ## Why
  Renamed threads can share names, so hints that suggest resuming directly
  by name are ambiguous. Issue #23181 asks for the picker hint to include
  the thread name and thread ID in parens so users can disambiguate
  safely.
  
  ## What
  - Adds a shared resume hint formatter for named threads: run `codex
  resume`, then select `<name> (<thread-id>)`.
  - Uses that hint for /rename confirmations, TUI session summaries, and
  CLI/TUI exit messages.
  - Keeps direct `codex resume <thread-id>` guidance for unnamed threads.
  
  ## Verification
  Manually verified that message after `/rename` and after `/exit` include
  session ID in parens.
  
  ---------
  
  Co-authored-by: Felipe Coury <felipe.coury@openai.com>

  Eric Traut · 2026-05-18 11:32:02 -07:00
  4ac3ea20a2
• goal: pause continuation loops on usage limits and blockers (#23094)

  Addresses #22833, #22245, #23067
  
  ## Why
  `/goal` can keep synthesizing turns even when the next turn cannot make
  meaningful progress. Hard usage exhaustion can replay failing turns, and
  repeated permission or external-resource blockers can keep burning
  tokens while waiting for user or system intervention.
  
  ## What changed
  - Add resumable `blocked` and `usageLimited` goal states. As with
  `paused`, goal continuation stops with these states.
  - Move to `usageLimited` after usage-limit failures.
  - Allow the built-in `update_goal` tool to set `blocked` only under
  explicit repeated-impasse guidance. Updated goal continuation prompt to
  specify that agent should use `blocked` only when it has made at least
  three attempts to get past an impasse.
  
  Most of the files touched by this PR are because of the small app server
  protocol update.
  
  ## Validation
  
  I manually reproduced a number of situations where an agent can run into
  a true impasse and verified that it properly enters `blocked` state. I
  then resumed and verified that it once again entered `blocked` state
  several turns later if the impasse still exists.
  
  I also manually reproduced the usage-limit condition by creating a
  simulated responses API endpoint that returns 429 errors with the
  appropriate error message. Verified that the goal runtime properly moves
  the goal into `usageLimited` state and TUI UI updates appropriately.
  Verified that `/goal resume` resumes (and immediately goes back into
  `ussageLImited` state if appropriate).
  
  
  ## Follow-up PRs
  
  Small changes will be needed to the GUI clients to properly handle the
  two new states.

  Eric Traut · 2026-05-18 11:28:53 -07:00
  0d344aca9b
• fix: harden plugin creator sharing validation (#22893)

  # Summary
  
  Before this change, the sample plugin creator could emit
  placeholder-heavy manifests that fail workspace sharing, and it chose a
  repo-local marketplace implicitly whenever it ran from inside a git
  checkout.
  
  This PR makes generated plugins share-ready by default. It switches
  creation to the personal marketplace unless the caller explicitly opts
  into repo-local paths, adds a validator that mirrors the workspace
  plugin ingestion contract, and updates the skill prompt and docs to
  describe the real flow.
  
  The goal is to stop malformed generated plugins before they reach
  sharing and to make the default placement match the personal marketplace
  behavior users expect.
  
  ## Changes
  
  - Generate share-safe plugin manifests instead of `[TODO: ...]`
  placeholder payloads.
  - Default plugin and marketplace creation to `~/plugins` and
  `~/.agents/plugins/marketplace.json`.
  - Keep repo-local marketplace creation available through explicit
  `--path` and `--marketplace-path` arguments.
  - Add `validate_plugin.py` to check manifests, companion files, skill
  frontmatter, skill agent YAML, asset paths, and backend-shaped contracts
  before sharing.
  - Refresh the plugin creator skill text, reference docs, and default
  prompt to describe validation and the personal default.
  
  ## Design decisions
  
  - The validator tracks the workspace ingestion schema directly,
  including the required `defaultPrompt` alias handling and skill
  `agents/openai.yaml` checks.
  - The validator keeps one intentional extra preflight rule: leftover
  `[TODO: ...]` placeholders are rejected before sharing even when a
  single placeholder would not independently violate backend type
  validation.
  - Repo-local creation stays possible, but it is now explicit instead of
  cwd-sensitive.
  
  ## Testing
  
  Tests: targeted Python syntax checks, plugin skill validation, staged
  diff whitespace validation, 15 generated plugin smoke runs, backend
  manifest-schema acceptance for all 15 generated bundles, and a git-repo
  cwd regression proving the creator still writes to the personal
  marketplace by default.

  efrazer-oai · 2026-05-18 11:22:42 -07:00
  d32cb2c6ac
• Upload rust full CI JUnit reports (#23273)

  ## Why
  
  `rust-ci-full` failures currently leave downstream investigation
  reconstructing basic test facts from raw logs. `cargo nextest` can emit
  standard JUnit XML for each lane, which gives us a small structured
  artifact for post-run failure analysis without changing the test
  execution model.
  
  ## What changed
  
  - enable nextest JUnit output in `codex-rs/.config/nextest.toml`
  - upload the lane-scoped JUnit XML artifact from each `rust-ci-full`
  test lane
  
  ## Verification
  
  - `rust-ci-full` run `26018931531` on head
  `52d77c60e79b36859d944ef28a36b014055c5c48` produced JUnit artifacts for
  macOS, Linux x64 remote, Windows x64, and Windows ARM64 test lanes
  - `rust-ci-full` run `26021241006` on the same head produced the missing
  Linux ARM JUnit artifact after the first run lost that runner before
  export
  - downloaded all five lane JUnit artifacts and verified each contains
  non-empty test counters and failure data

  starr-openai · 2026-05-18 11:10:37 -07:00
  8c14b08dd1
• Simplify legacy Windows sandbox ACL persistence (#22569)

  ## Why
  
  The legacy Windows sandbox still carried a `persist_aces` mode switch,
  even though the only path that meaningfully applies filesystem ACEs
  today is `workspace-write`, which already uses the persistent behavior.
  Legacy read-only sessions rely on the read-only capability SID rather
  than per-command filesystem ACE mutation, so the temporary cleanup
  branch had become conceptual overhead without a corresponding behavioral
  need.
  
  Removing that split makes the ACL lifecycle match the current sandbox
  model more directly and trims the guard/revocation plumbing from the
  legacy launcher paths.
  
  ## What changed
  
  - Removed the `persist_aces` parameter from legacy ACL preparation.
  - Made legacy deny-read handling always use the persistent
  reconciliation path.
  - Dropped guard tracking and post-exit ACE revocation from both capture
  and unified-exec legacy flows.
  - Kept workspace `.codex` / `.agents` protection tied directly to
  `WorkspaceWrite` instead of an intermediate persistence flag.
  
  ## Verification
  
  - `cargo fmt -p codex-windows-sandbox`
  - `git diff --check`
  - `cargo test -p codex-windows-sandbox`
    - 85 passed, 2 ignored, 2 (unrelated) failed locally.

  iceweasel-oai · 2026-05-18 11:00:03 -07:00
  b1c13b6fe5
• Fix remote turn diff display roots (#23261)

  ## Why
  
  `TurnDiffTracker` computes a display root so turn diffs can be rendered
  repo-relative. For remote exec-server turns, the selected turn `cwd` may
  exist only inside the selected environment, but `run_turn` was
  discovering the git root through the local host filesystem. When that
  lookup failed, nested remote-session diffs fell back to the nested `cwd`
  and showed `/tmp/...`-prefixed paths instead of repo-relative paths.
  
  ## What changed
  
  - Resolve the diff display root from the primary selected turn
  environment when one exists, using that environment's filesystem and
  `cwd`.
  - Add `codex_git_utils::get_git_repo_root_with_fs(...)` so git-root
  discovery can run against an `ExecutorFileSystem`, including remote
  environments.
  - Reuse that helper from `resolve_root_git_project_for_trust(...)` and
  add coverage for `.git` gitdir-pointer detection.
  
  ## Validation
  
  - Devbox Bazel: `//codex-rs/core:core-unit-tests
  --test_filter=get_git_repo_root_with_fs_detects_gitdir_pointer`
  - Devbox Docker-backed remote-env repro: `//codex-rs/core:core-all-test
  --test_filter=apply_patch_turn_diff_paths_stay_repo_relative_when_session_cwd_is_nested`

  starr-openai · 2026-05-18 10:53:49 -07:00
  9286ff2805
• fix(tui): show shutdown feedback on exit (#23323)

  ## Why
  
  Ctrl+C can take a noticeable amount of time to finish when the TUI is
  waiting for the app-server thread shutdown path to complete. Before this
  change, the UI could look like it had not accepted the shutdown request
  because the composer and cursor remained in their normal interactive
  state during that wait.
  
  This PR makes the accepted shutdown visible immediately. It does not add
  an artificial sleep or change the shutdown timeout; it only draws one
  final feedback frame before continuing through the existing shutdown
  flow.
  
  ## What Changed
  
  - On `ExitMode::ShutdownFirst`, the TUI now renders shutdown feedback
  before awaiting the existing thread shutdown future.
  - The bottom pane disables composer input, which hides the cursor
  through the existing disabled-input cursor path.
  - The composer shows `Shutting down...` as the disabled input hint and
  suppresses footer content so the shutdown acknowledgement is not
  competing with shortcut/status text.
  - The logout path uses the same feedback path before shutting down.
  
  ## How to Test
  
  1. Start Codex from this branch.
  2. Press `Ctrl+C` to request shutdown.
  3. If shutdown takes long enough to observe, confirm the composer
  changes to `› Shutting down...`, the cursor disappears, and no footer
  hint is rendered below it.
  4. Regression check: repeat with text already typed in the composer and
  confirm the visible row still switches to `Shutting down...` while the
  draft remains preserved internally until the process exits.
  
  Targeted tests:
  
  - `cargo test -p codex-tui
  shutdown_in_progress_disables_input_and_uses_hint_without_footer`
  - `cargo test -p codex-tui bottom_pane::footer::tests::`
  
  ## Local Validation Note
  
  `cargo test -p codex-tui` still aborts in
  `app::tests::discard_side_thread_removes_agent_navigation_entry` with a
  stack overflow. That same test also failed when run alone locally, and
  the failure appears unrelated to this shutdown feedback path.

  Felipe Coury · 2026-05-18 14:41:14 -03:00
  bb43044cba
• windows: link MSVC release binaries with static CRT (#22905)

  ## Why
  
  Windows release artifacts currently import `VCRUNTIME140.dll` and
  `VCRUNTIME140_1.dll`. That becomes observable on clean Windows machines
  that do not already have the VC++ runtime available globally:
  
  - Desktop Store launches can fail after the app relocates `codex.exe`
  out of `WindowsApps`, which means an MSIX-level VCLibs dependency does
  not protect the relocated CLI/app-server process.
  - The npm CLI path reproduces the same missing-DLL startup failure when
  `System32\vcruntime140_1.dll` is hidden and `PATH` is stripped of
  incidental fallback copies.
  
  In that setup, the existing Windows binary exits with `0xC0000135` /
  `-1073741515` before Codex code runs.
  
  ## What changed
  
  - Add `-C target-feature=+crt-static` to the existing MSVC-only Cargo
  rustflags in `codex-rs/.cargo/config.toml`.
  - Preserve the existing `/STACK:8388608` linker setting in the same
  target block.
  
  This keeps the change scoped to Windows MSVC builds and avoids altering
  non-Windows or GNU target behavior.
  
  ## Verification
  
  I built an x64 Windows release probe with static CRT linkage and the
  normal 8 MiB stack reserve, then verified:
  
  - `dumpbin /dependents codex.exe` no longer reports `VCRUNTIME140.dll`
  or `VCRUNTIME140_1.dll`.
  - `dumpbin /headers codex.exe` reports `800000 size of stack reserve`.
  - With `System32\vcruntime140_1.dll` hidden and `PATH` stripped to
  Windows system directories only:
    - the old npm CLI path exits `-1073741515`
  - the rebuilt static-CRT `codex.exe --version` succeeds with exit code
  `0`
    - the rebuilt TUI starts successfully
  
  I also confirmed `codex.exe app-server --listen ws://127.0.0.1:0` starts
  and binds normally with the static-CRT artifact.

  iceweasel-oai · 2026-05-18 10:32:33 -07:00
  d335b00212
• nit: read prompt (#23332)
  jif-oai · 2026-05-18 19:25:27 +02:00
  3f2b7ede0b
• [codex] Remove legacy shell output formatting paths (#22706)

  ## Why
  
  The client and tool pipeline still carried compatibility code for legacy
  structured shell output. Current shell and apply_patch responses are
  already plain text for model consumption, so keeping a
  JSON-serialization path plus shell-item rewrite logic makes the request
  formatter and tests preserve a format we do not need anymore.
  
  ## What Changed
  
  - Removed the client-side shell output rewrite from
  `core/src/client_common.rs`.
  - Removed the structured exec-output formatter and the shell `freeform`
  switch so tool emitters use one model-facing formatter.
  - Collapsed apply_patch/shell serialization tests around the remaining
  plain-text output expectations and removed duplicate one-variant
  parameterized cases.
  - Kept the `ApplyPatchModelOutput::ShellCommandViaHeredoc` compatibility
  input shape, but no longer treats it as a separate output-format mode.
  
  ## Validation
  
  - `cargo test -p codex-core client_common`
  - `cargo test -p codex-core shell_serialization`
  - `cargo test -p codex-core apply_patch_cli`
  - `just fix -p codex-core`
  
  ## Documentation
  
  No external Codex documentation update is needed.

  pakrym-oai · 2026-05-18 09:57:54 -07:00
  82061660ae
• [1 of 2] Optimize TUI startup terminal probes (#23175)

  ## Why
  
  Codex TUI startup still feels slower than 0.117.0 after the app-server
  move in 0.118.0. A visible chunk of launch-to-input latency comes from
  serial terminal startup probes: cursor position, keyboard enhancement
  support, and default foreground/background color queries can each wait
  on terminal responses before the first usable frame.
  
  Refs #16335.
  
  ## What
  
  This PR batches the terminal startup probes into one bounded probe. It
  also reuses the probed cursor position and default colors during TUI
  setup, fast-paths the primary-device-attributes fallback as keyboard
  enhancement unsupported, and keeps lightweight startup timing logs for
  future tuning.
  
  The startup telemetry is intentionally left in production: it records
  phase timings for terminal probes and initial-frame scheduling so future
  startup regressions can be diagnosed from normal logs rather than
  re-adding one-off debug instrumentation.
  
  ## Benchmark
  
  In the local pty startup benchmark, the pre-optimization `main` baseline
  was about 250.5ms median from launch to accepted chat input. This
  probe-only branch measured about 152ms median, for an approximate
  savings of 95-100ms.
  
  ## Stack
  
  1. [#23175: [1 of 2] Optimize TUI startup terminal
  probes](https://github.com/openai/codex/pull/23175) — this PR
  2. [#23176: [2 of 2] Start fresh TUI thread in
  background](https://github.com/openai/codex/pull/23176) — layered on
  this PR
  
  ## Verification
  
  - `cargo test -p codex-tui`

  Eric Traut · 2026-05-18 09:04:02 -07:00
  adca1b643f
• Hide ChatGPT usage link for non-OpenAI status (#23127)

  Addresses #22778
  
  ## Summary
  
  Provider deployments such as Bedrock manage rate limits and billing
  outside ChatGPT, so the `/status` link to the ChatGPT usage page is
  irrelevant and confusing for those users. Custom providers that are
  explicitly configured to use OpenAI/ChatGPT auth still point at
  OpenAI-backed usage, so they should keep the link.
  
  ## Changes
  
  - Render the ChatGPT usage note only when the configured provider uses
  OpenAI auth.
  - Keep the note hidden when `/status` displays a provider such as
  Bedrock that manages limits elsewhere.
  - Add regression coverage for both Bedrock and a custom OpenAI-auth
  proxy provider.
  
  ## Manual Repro
  
  1. Configure Codex with a non-OpenAI-auth provider, for example
  `model_provider = "amazon-bedrock"`.
  2. Start the TUI and run `/status`.
  3. Confirm the status card shows the custom provider, for example `Model
  provider: Amazon Bedrock`, and does not show
  `https://chatgpt.com/codex/settings/usage`.
  4. Configure a custom provider that proxies to OpenAI and has
  OpenAI/ChatGPT auth enabled.
  5. Run `/status` again and confirm the ChatGPT usage link appears for
  that OpenAI-auth provider.

  Eric Traut · 2026-05-18 09:02:38 -07:00
  e734cb5713
• Fix TUI stream cleanup after turn errors (#23128)

  ## Summary
  
  Fixes #22726.
  
  After a Responses stream disconnect, the live TUI could keep accepting
  prompts while leaving partially streamed assistant output in its
  transient streaming-cell form. That made fenced diffs or SVG/XML-like
  content appear as raw transcript text until the user closed the TUI and
  resumed the same session, which rebuilt the transcript from saved
  history.
  
  This change finalizes the active answer stream before generic
  failed-turn cleanup clears the stream controller, so the live transcript
  takes the same source-backed markdown consolidation path as a successful
  turn.
  
  ## Reviewer repro
  
  1. Start a local Codex TUI session.
  2. Trigger an assistant turn that streams markdown content, especially a
  fenced diff or SVG/XML-like block.
  3. Force or encounter a non-retry stream disconnect before the turn
  completes.
  4. Continue using the same still-open TUI session.
  5. Before this fix, the live history can stay raw/plain even though
  `codex resume` renders the same session normally.
  6. After this fix, the failed-turn path consolidates the partial stream
  before rendering the error, so the live TUI keeps normal transcript
  rendering.

  Eric Traut · 2026-05-18 09:00:57 -07:00
  deb159d9ff
• Support --output-schema for exec resume (#23123)

  ## Why
  
  `codex exec resume` should have the same structured-output support as
  top-level `codex exec`. Without `--output-schema`, multi-turn automation
  has to choose between resumed session context and schema-validated JSON
  output.
  
  Fixes #22998.
  
  ## What changed
  
  - Marked `--output-schema` as a global `codex exec` flag so it can be
  passed after `resume`.
  - Reused the existing output schema plumbing so resumed turns attach the
  schema to the final response request while preserving session context.

  Eric Traut · 2026-05-18 08:55:22 -07:00
  af6ffb6ebb
• tui: keep cleared Fast tier from reappearing after side-thread resume (#23121)

  ## Why
  
  After turning Fast mode off in the TUI, returning from a side thread
  could make `Fast` appear again in the main chat widget. The opt-out
  itself was still persisted; the display was being rebuilt from stale
  cached `ThreadSessionState` data, which made it look like Fast had been
  re-enabled.
  
  Fixes #23104.
  
  ## What changed
  
  - Keep the active thread's cached `service_tier` in sync whenever the
  user persists a service-tier selection.
  - Update both the primary-thread snapshot and the thread event store so
  restored TUI state reflects the current tier.
  - Add a focused regression test for clearing a cached Fast tier.
  
  ## Manual repro
  
  1. Start a TUI session where `Fast` is enabled by default.
  2. Run `/fast` and turn Fast mode off. Confirm `Fast` disappears from
  the chat widget display.
  3. Re-enter thread navigation via either path:
     - Run `/side test`, then return to the main thread.
     - Run `/agent`, enter a child thread, then return to the main thread.
  4. Before this fix, `Fast` reappears in the main chat widget display
  even though the opt-out was already persisted.
  5. After this fix, `Fast` stays cleared.
  
  ## Verification
  
  - `cargo test -p codex-tui
  app::thread_session_state::tests::service_tier_sync_updates_active_cached_session
  -- --exact`

  Eric Traut · 2026-05-18 08:52:18 -07:00
  fce10e009d