6699 Commits

This Branch

This Branch

All Branches

• add standalone websearch api client (#23655)

  add standalone web search request types and a `codex-api` client ahead
  of the extension-contributed search tool.
  
  this adds typed commands/settings and opaque encrypted output handling
  for the new standalone search flow. the endpoint types are close to
  finalized but may still shift slightly as that API settles.

  sayan-oai · 2026-05-20 11:38:21 -07:00
  ed6d73b3b9
• [codex] Preserve failed goal accounting flushes (#23717)

  ## What
  - Preserve database accounting failures from the goal extension instead
  of collapsing them into `None`
  - Warn with turn/tool context when a flush fails
  - Keep stop/abort accounting snapshots alive when the final flush did
  not persist
  
  ## Why
  PR #23696 can finish and discard a turn snapshot after
  `account_thread_goal_usage` fails. That loses the final accumulated
  accounting state silently. This follow-up keeps that failure explicit
  and avoids deleting the local snapshot in the failing path.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-goal-extension`

  jif-oai · 2026-05-20 20:37:27 +02:00
  d84b824d53
• install: consume Codex package archives (#23636)

  ## Summary
  
  Standalone installs should exercise the same canonical package archive
  layout that release builds produce, rather than unpacking npm platform
  packages and reconstructing a parallel install tree.
  
  This updates `install.sh` and `install.ps1` to prefer
  `codex-package-<target>.tar.gz` plus `codex-package_SHA256SUMS`
  introduced in https://github.com/openai/codex/pull/23635, authenticate
  the checksum manifest against GitHub release metadata, verify the
  selected package archive against the authenticated manifest, and install
  the package archive directly.
  
  ## Compatibility Notes
  
  Package installs still leave a compatibility command at `current/codex`
  for managed daemon flows, while visible command shims point at
  `bin/codex` inside the package layout.
  
  Recent releases that predate package archives still publish per-platform
  npm artifacts, so both installers keep a legacy platform npm fallback
  for those versions and verify those archives against release metadata
  directly.
  
  Releases old enough to publish only the single root
  `codex-npm-<version>.tgz` archive are intentionally out of scope. The
  installers fail clearly when neither package archives nor per-platform
  npm archives are present.
  
  On Windows, the runtime helper lookups now recognize package-layout
  installs where `codex.exe` runs from `bin/`, so
  `codex-command-runner.exe` and `codex-windows-sandbox-setup.exe` resolve
  from the top-level `codex-resources/` directory. The direct-sibling and
  older sibling-resource fallbacks are preserved.
  
  ## Test plan
  
  - `sh -n scripts/install/install.sh`
  - `bash -n scripts/install/install.sh`
  - `pwsh -NoProfile -Command '$tokens=$null; $errors=$null; $null =
  [System.Management.Automation.Language.Parser]::ParseFile("scripts/install/install.ps1",
  [ref]$tokens, [ref]$errors); if ($errors.Count) { $errors | Format-List
  *; exit 1 }'`
  - `HOME="$home_dir" CODEX_HOME="$tmp_dir/codex-home"
  CODEX_INSTALL_DIR="$bin_dir" PATH="$bin_dir:$PATH" sh
  scripts/install/install.sh --release 0.125.0`
  - Verified the 0.125.0 isolated install leaves the visible command
  pointed at `current/codex` and includes the legacy `codex-resources/rg`
  payload.
  - `cargo test -p codex-windows-sandbox`
  - `just fix -p codex-windows-sandbox`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23636).
  * #23638
  * #23637
  * __->__ #23636

  Michael Bolin · 2026-05-20 11:20:11 -07:00
  110b30d545
• feat: add turn_id and truncation_policy to extension tool calls (#23666)

  ## Why
  
  Extension-owned tools currently receive a stripped `ToolCall` with only
  `call_id`, `tool_name`, and `payload`.
  That makes extension work that needs turn-local execution context
  awkward, especially web-search extension work that needs the active
  `truncation_policy` at tool invocation time.
  
  Reconstructing that value from config or `ExtensionData` would be
  indirect and could drift from the actual turn context, so the cleaner
  fix is to pass the needed turn metadata directly on the extension-facing
  invocation type.
  
  ## What changed
  
  - added `turn_id` and `truncation_policy` to `codex_tools::ToolCall`
  - populated those fields when core adapts `ToolInvocation` into an
  extension tool call
  - added a focused adapter test that verifies extension executors receive
  the forwarded turn metadata
  - updated the memories extension tests to construct the richer
  `ToolCall`
  - added the `codex-utils-output-truncation` dependency to `codex-tools`
  and refreshed lockfiles
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-memories-extension`
  - `cargo test -p codex-core passes_turn_fields_to_extension_call`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  jif-oai · 2026-05-20 20:14:41 +02:00
  c5bd131567
• Sync TUI thread settings through app server (#23507)

  Builds on #23502.
  
  ## Why
  
  #23502 adds the app-server `thread/settings/update` API and matching
  `thread/settings/updated` notification. The TUI already lets users
  change thread-scoped settings such as model, reasoning effort, service
  tier, approvals, permissions, personality, and collaboration mode, but
  those updates need to flow through the app server so embedded and
  connected clients observe the same thread state.
  
  This is a rework (simplification) of PR
  https://github.com/openai/codex/pull/22510. It has the same
  functionality, but the underlying `thread/settings/update` api is now
  simpler in that it no longer returns the effective settings as a
  response. Now, clients receive the effective settings only through the
  `thread/settings/updated` notification.
  
  ## What Changed
  
  This updates the TUI to send `thread/settings/update` whenever those
  thread-scoped settings change and to treat the RPC response as the
  authoritative acknowledgement. It also routes `thread/settings/updated`
  notifications back into cached session state and the visible chat widget
  so active and inactive threads stay in sync after app-server-originated
  changes.
  
  The implementation is kept to the TUI layer: settings conversion and
  merge logic live under `codex-rs/tui/src/app/thread_settings.rs`, with
  dispatch/routing hooks in the existing app and chat widget paths.
  
  ## Verification
  
  I manually tested using `codex app-server --listen unix://` and then
  launching two copies of the TUI that use the same local app server. I
  then resumed the same thread on both and verified that changes like plan
  mode, fast mode, model, reasoning effort, etc. are reflected "live" in
  the second client when modified in the first and vice versa.

  Eric Traut · 2026-05-20 11:05:14 -07:00
  edc48e4612
• Add thread/settings/update app-server API (#23502)

  ## Why
  
  App-server clients need a way to update a thread's next-turn settings
  without starting a turn, adding transcript content, or waiting for turn
  lifecycle events. This gives settings UI a direct path for durable
  thread settings while clients observe the eventual effective state
  through a notification.
  
  This is a simplified rework of PR
  https://github.com/openai/codex/pull/22509. In particular, it changes
  the `thread/settings/update` api to return immediately rather than
  waiting and returning the effective (updated) thread settings. This
  makes the new api consistent with `turn/start` and greatly reduces the
  complexity of the implementation relative to the earlier attempt.
  
  ## What Changed
  
  - Adds experimental `thread/settings/update` with partial-update request
  fields and an empty acknowledgment response.
  - Adds experimental `thread/settings/updated`, carrying full effective
  `ThreadSettings` and scoped by `threadId` to subscribed clients for the
  affected thread.
  - Shares durable settings validation with `turn/start`, including
  `sandboxPolicy` plus `permissions` rejection and `serviceTier: null`
  clearing.
  - Emits the same settings notification when `turn/start` overrides
  change the stored effective thread settings.
  - Regenerates app-server protocol schema fixtures and updates
  `app-server/README.md`.

  Eric Traut · 2026-05-20 11:03:20 -07:00
  771a4e74ac
• windows-sandbox: add resolved permissions helper (#22896)

  ## Why
  
  The Windows sandbox migration away from the legacy `SandboxPolicy`
  abstraction needs a small local bridge before IPC and core wiring can
  move to `PermissionProfile`. Leaf helpers currently branch directly on
  `WorkspaceWrite`, which spreads legacy assumptions through path planning
  and token setup code.
  
  This PR introduces a Windows-local resolved permissions view so those
  helpers can ask Windows-specific questions about runtime
  filesystem/network permissions without matching on the legacy policy
  enum everywhere.
  
  ## What changed
  
  - Added `ResolvedWindowsSandboxPermissions` in
  `windows-sandbox-rs/src/resolved_permissions.rs`, with legacy
  `SandboxPolicy` constructors for the current call sites.
  - Moved `allow.rs` writable-root and read-only-subpath planning onto the
  resolved permissions type.
  - Preserved Windows `TEMP`/`TMP` writable-root behavior when the
  effective policy includes writable tmpdir access.
  - Avoided resolving Unix `:slash_tmp` or parent-process `TMPDIR` while
  computing Windows writable roots.
  - Reused the shared allow-path result for setup write-root gathering and
  routed network-block selection through the resolved abstraction.
  
  ## Verification
  
  - `cargo test -p codex-windows-sandbox`
  - `just fix -p codex-windows-sandbox`
  - GitHub CI restarted on the amended commit; Windows Bazel is the
  required signal for the Windows-only code paths.
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22896).
  * #23715
  * #23714
  * #23167
  * #22923
  * #22918
  * __->__ #22896

  Michael Bolin · 2026-05-20 17:30:46 +00:00
  2b4898cc47
• fix(app-server): speed up shutdown (#23578)

  ## Why
  
  Pressing `Ctrl+C` or `Ctrl+D` in the TUI could make Codex pause during
  shutdown when app-server background work still held outbound sender
  clones.
  
  Shutdown tracing against the current `~/.codex` path found three
  relevant holders:
  
  - `SkillsWatcher` kept its event-loop task alive until the shutdown
  timeout path.
  - `AppServerAttestationProvider` retained a strong
  `Arc<OutgoingMessageSender>`, which could keep outbound teardown waiting
  after the processor task had exited.
  - A background `apps/list` task could still own an outbound sender when
  shutdown began, causing the in-process app-server runtime to wait for
  its outbound channel to close.
  
  ## What Changed
  
  - Give `SkillsWatcher` an explicit shutdown `CancellationToken` and
  cancel it from app-server teardown so its event loop drops the outbound
  sender promptly.
  - Change `AppServerAttestationProvider` to keep a
  `Weak<OutgoingMessageSender>` and return immediately when it can no
  longer be upgraded.
  - Give `AppsRequestProcessor` a shutdown `CancellationToken` and cancel
  in-flight background `apps/list` work during teardown.
  
  ## How to Test
  
  1. Start Codex TUI from a real home configuration.
  2. Press `Ctrl+C`.
  3. Confirm Codex exits promptly instead of pausing during shutdown.
  4. Repeat with `Ctrl+D` and confirm the same prompt exit path.
  
  Focused manual trace validation from the investigation:
  
  - Before the full fix, reproduced shutdown traces showed outbound
  teardown waiting on lingering owners, including `attestation.provider=1`
  and later `apps.list.task=1`.
  - After the fix, fresh real-home `Ctrl+D` traces showed
  `app_server.runtime.outbound_state_after_processor_join` with
  `owners=none`, `app_server.runtime.wait_outbound_handle = 0ms`, and
  total TUI app-server shutdown around `18ms`.
  
  Targeted validation:
  
  - `RUST_MIN_STACK=8388608 cargo test -p codex-app-server`

  Felipe Coury · 2026-05-20 17:30:19 +00:00
  050a2e2668
• [2 of 2] Start fresh TUI thread in background (#23176)

  ## Why
  
  After the terminal-probe work in #23175, fresh-session startup still
  waits for `thread/start` before the chat input can become usable. The
  chat widget already has the machinery to hold early submissions until a
  session is configured, so fresh `thread/start` does not need to stay on
  the input-ready hot path.
  
  Refs #16335.
  
  ## What
  
  This PR starts fresh app-server threads in a background task, reports
  completion through a startup app event, and attaches the primary session
  once `thread/start` returns. Resume and fork startup paths remain
  synchronous.
  
  ## Benchmark
  
  In the local pty startup benchmark, this PR's pre-optimization base
  branch, #23175, measured about 152ms median from launch to accepted chat
  input. The stacked result measured about 66ms median, for an approximate
  additional savings of 85-95ms. For broader context, the original `main`
  baseline before either startup optimization was about 250.5ms median. We
  also measured Codex 0.117.0 on the same machine at about 64.6ms median,
  so the stacked branch is back in the old-startup-time range.
  
  ## Stack
  
  1. [#23175: [1 of 2] Optimize TUI startup terminal
  probes](https://github.com/openai/codex/pull/23175) — base PR
  2. [#23176: [2 of 2] Start fresh TUI thread in
  background](https://github.com/openai/codex/pull/23176) — this PR
  
  ## Verification
  
  - `cargo test -p codex-tui`

  Eric Traut · 2026-05-20 10:00:33 -07:00
  c0f7e1b99f
• feat: account active goal progress in the goal extension (#23696)

  ## Why
  
  The goal extension can create and surface goals, but the live
  turn-accounting path still stopped short of persisting active-goal
  progress. That leaves token and wall-clock usage, plus
  `ThreadGoalUpdated` events, out of sync with the extension boundary once
  work actually advances or a goal transitions out of active state.
  
  ## What changed
  
  - Teach `GoalAccountingState` to track the current turn, active goal,
  token deltas, and wall-clock progress snapshots against the persisted
  goal id.
  - Flush active-goal accounting from tool-finish, turn-stop, and
  turn-abort lifecycle hooks, and emit `ThreadGoalUpdated` events when
  persisted progress changes.
  - Route `create_goal` and `update_goal` through the same accounting
  state so new goals start from the right baseline, final progress is
  flushed before status changes, and `update_goal` can mark a goal
  `blocked` as well as `complete`.
  - Keep budget-limited goals accruing through the end of the turn while
  clearing local active-goal state once a turn or explicit update is
  finished.
  - Expand backend and lifecycle coverage around store ids, baseline
  reset, tool-finish accounting, budget-limited carry-through, and
  blocked-goal updates.
  
  ## Testing
  
  - Added focused backend coverage in
  `codex-rs/ext/goal/tests/goal_extension_backend.rs` for baseline reset,
  tool-finish accounting, budget-limited turns, and blocked-goal updates.
  - Extended `codex-rs/core/src/session/tests.rs` to assert that lifecycle
  inputs expose the expected session, thread, and turn store ids.

  jif-oai · 2026-05-20 18:36:37 +02:00
  d4f842f3b3
• feat: Add btw alias for side slash command (#23592)
  anp-oai · 2026-05-20 15:49:35 +00:00
  f198ca115b
• release: publish Codex package archive checksums (#23635)

  ## Summary
  
  Standalone installers and other downstream package consumers need a
  stable checksum source for the canonical package archives. Relying on
  per-asset metadata makes that harder to consume uniformly, especially
  when several package archives are produced in the same release.
  
  This keeps the `codex-package-*.tar.gz` and
  `codex-app-server-package-*.tar.gz` assets in the GitHub Release upload
  set and adds `codex-package_SHA256SUMS` to `dist/` before the release is
  created. The manifest contains one SHA-256 line per package archive and
  fails the release job if no package archives are present.
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23635).
  * #23638
  * #23637
  * #23636
  * __->__ #23635

  Michael Bolin · 2026-05-20 08:48:04 -07:00
  e9f59e30d9
• runtime: use install context for bundled bwrap (#23634)

  ## Summary
  
  The Linux sandbox should find bundled `bwrap` through the same
  package-layout abstraction as the rest of the runtime, instead of
  maintaining a separate standalone-specific lookup path.
  
  This adds an `InstallContext` helper for bundled resources and updates
  `codex-linux-sandbox` to ask the current install context for
  `codex-resources/bwrap` before falling back to the old
  executable-relative probes. The tests cover npm-style, standalone, and
  canonical package layouts so `bwrap` lookup follows the package
  structure introduced earlier in the stack.
  
  ## Test plan
  
  - `cargo test -p codex-install-context`
  - `cargo test -p codex-linux-sandbox --lib`
  - `just fix -p codex-install-context -p codex-linux-sandbox`
  - `just bazel-lock-check`
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23634).
  * #23638
  * #23637
  * #23636
  * #23635
  * __->__ #23634

  Michael Bolin · 2026-05-20 08:24:43 -07:00
  b0b383bea3
• [codex] Hide deferred tools from code mode prompt (#23605)

  ## Why
  
  `code_mode_only_guides_all_tools_search_and_calls_deferred_app_tools`
  was failing because code-mode prompt generation used the same nested
  tool spec list for both the model-visible `exec` guide and the runtime
  `ALL_TOOLS` surface. That allowed deferred MCP/app tools, such as
  `calendar_timezone_option_99`, to leak into the `exec` description even
  though they should only be discoverable through `ALL_TOOLS` at runtime.
  
  ## What changed
  
  Split code-mode nested tool planning into two sets in
  `core/src/tools/spec_plan.rs`:
  
  - runtime nested tool specs still include deferred tools, so
  `tools[...]` and `ALL_TOOLS` can call them
  - `exec` prompt docs only render non-deferred tools, so deferred app
  tools stay out of the model-visible guide
  
  ## Validation
  
  - `cargo test -p codex-core --test all
  code_mode_only_guides_all_tools_search_and_calls_deferred_app_tools --
  --nocapture`
  - looped the same focused test 5 additional times with `cargo test -q -p
  codex-core --test all
  code_mode_only_guides_all_tools_search_and_calls_deferred_app_tools`

  pakrym-oai · 2026-05-20 08:09:45 -07:00
  a52c91d8b5
• feat: expose turn-start metadata to extensions (#23688)

  ## Why
  
  The goal extension needs more context when a turn starts than
  `turn_store` alone provides.
  
  In particular, goal accounting needs the stable turn id, the effective
  collaboration mode, and the cumulative token-usage baseline captured at
  turn start so it can:
  
  - suppress goal accounting for plan-mode turns
  - compute exact per-turn deltas from cumulative `total_token_usage`
  snapshots instead of relying on the most recent usage event alone
  - keep the extension-owned accounting path aligned with the host turn
  lifecycle
  
  ## What
  
  - extend `codex_extension_api::TurnStartInput` to expose `turn_id`,
  `collaboration_mode`, and `token_usage_at_turn_start`
  - pass the full `TurnContext` plus the captured token-usage baseline
  through the turn-start lifecycle emission path
  - initialize goal turn accounting from the turn-start baseline and
  collaboration mode
  - switch goal token accounting to compute deltas from cumulative
  `total_token_usage` snapshots
  - add coverage for the new turn-start lifecycle fields and for
  goal-accounting baseline behavior
  
  ## Testing
  
  - added `turn_start_lifecycle_exposes_turn_metadata_and_token_baseline`
  in `codex-rs/core/src/session/tests.rs`
  - added `ext/goal/tests/accounting.rs` coverage for baseline-aware goal
  accounting and plan-mode suppression

  jif-oai · 2026-05-20 15:54:29 +02:00
  59507b8491
• feat: async turn item process (#23692)

  Mechanical change

  jif-oai · 2026-05-20 15:30:01 +02:00
  1392a2a770
• feat: async approval contrib (#23690)
  jif-oai · 2026-05-20 15:13:54 +02:00
  f64fce61b3
• feat: wire goal extension tools to the dedicated goal store (#23685)

  ## Why
  
  `ext/goal` already had the tool specs and contributor wiring for
  `/goal`, but the installed tools still depended on a placeholder backend
  that always errored. That meant the extension could not actually own
  goal persistence even though the dedicated `thread_goals` store already
  exists.
  
  This change wires the extension tools directly to the dedicated goal
  store so the extension can create, read, and complete goals against real
  state instead of falling back to host-side placeholders.
  
  ## What changed
  
  - make `install_with_backend(...)` require
  `Arc<codex_state::StateRuntime>` so goal storage is always available
  when the extension is installed
  - remove the unused no-backend/public backend abstraction from
  `ext/goal` and have the tool executors talk directly to `StateRuntime`
  - map `thread_goals` rows into the existing protocol response shape for
  `get_goal`, `create_goal`, and `update_goal`
  - preserve current thread-list behavior by filling an empty thread
  preview from the goal objective when a goal is created through the
  extension path
  - add integration coverage for the installed tool surface, including
  successful goal creation and duplicate-create rejection
  
  ## Testing
  
  - `cargo test -p codex-goal-extension`

  jif-oai · 2026-05-20 14:44:17 +02:00
  b555dd5d1d
• fix: main (#23675)

  Fix main due to conflicting merges
  This is only fixing some imports and mechanics

  jif-oai · 2026-05-20 12:27:39 +02:00
  51d6616431
• feat: rename 2 (#23668)

  Just a mechanical renaming

  jif-oai · 2026-05-20 12:11:44 +02:00
  9483b09ea4
• feat: rename 3 (#23669)

  Just a mechanical renaming

  jif-oai · 2026-05-20 12:07:06 +02:00
  66d5edf825
• feat: rename 1 (#23667)

  Just a mechanical renaming

  jif-oai · 2026-05-20 12:05:58 +02:00
  93456320ef
• Add timeout for remote compaction requests (#23451)

  ## Why
  
  Remote compaction currently sends a unary `POST /responses/compact` and
  waits for the full response before replacing history or emitting the
  completed `ContextCompaction` item. Unlike normal `/responses` streaming
  requests, this unary compact request had no timeout boundary. If the
  backend accepts the request and then stalls before returning a body, the
  existing request retry policy never sees a transport error, so the
  compact turn can remain stuck after the started item with no completion
  or actionable error.
  
  That matches the reported hang shape in issues such as #18363, where
  logs show `responses/compact` was posted but no corresponding compact
  completion followed. A bounded request timeout gives the existing retry
  policy a concrete timeout error to retry instead of letting the user sit
  indefinitely on automatic context compaction.
  
  ## What
  
  - Add a request timeout to legacy `/responses/compact` calls.
  - Size that timeout from the provider stream idle timeout with a
  conservative multiplier, so the default compact attempt gets 20 minutes
  rather than the 5 minute stream idle window.
  - Map API transport timeouts to a request timeout error instead of the
  child-process timeout message.
  
  ## Testing
  
  - Not run (per request; CI will cover).

  jif-oai · 2026-05-20 11:56:00 +02:00
  18cefba922
• Migrate exec-server remote registration to environments (#23633)

  ## Summary
  - migrate exec-server remote registration naming from executor to
  environment
  - align CLI, public Rust exports, registry error messages, and relay
  test fixtures with the environment registry contract
  - keep the live registration path and response model consistent with
  `/cloud/environment/{environment_id}/register`
  
  ## Verification
  - `cargo test -p codex-exec-server
  remote::tests::register_environment_posts_with_auth_provider_headers
  --manifest-path /Users/richardlee/code/codex/codex-rs/Cargo.toml`
  - `cargo test -p codex-exec-server --test relay
  multiplexed_remote_environment_routes_independent_virtual_streams
  --manifest-path /Users/richardlee/code/codex/codex-rs/Cargo.toml`
  - `cargo check -p codex-cli --manifest-path
  /Users/richardlee/code/codex/codex-rs/Cargo.toml` (still running when PR
  opened; will update after completion if needed)

  richardopenai · 2026-05-20 00:25:04 -07:00
  000bf5ce6d
• add encryptedcontent to functioncalloutput (#23500)

  add new `EncryptedContent` variant to `FunctionCallOutputContentItem`
  ahead of standalone websearch.
  
  we need to be able to receive and pass encrypted function call output
  from the new web search endpoint back to responsesapi, as we cannot
  expose direct search results.

  sayan-oai · 2026-05-19 23:47:48 -07:00
  34aad43684
• runtime: detect Codex package layout (#23596)

  ## Why
  
  The package-builder stack now creates a canonical Codex package
  directory where the entrypoint lives under `bin/`, bundled helper
  resources live under `codex-resources/`, and bundled PATH-style tools
  live under `codex-path/`. That layout is not specific to the standalone
  installer: npm, brew, install scripts, and manually unpacked artifacts
  should all be able to use the same package shape.
  
  The Rust runtime still only knew about the legacy standalone release
  layout, where resources sit next to the executable. A packaged binary
  therefore would not identify its package root or prefer the bundled `rg`
  from `codex-path/`.
  
  ## What changed
  
  - Adds `CodexPackageLayout` to `codex-install-context` and detects it
  from an executable path shaped like `<package>/bin/<entrypoint>` when
  `<package>/codex-package.json` is present.
  - Splits `InstallContext` into an install `method` plus an optional
  package layout so the layout is shared across npm, bun, brew,
  standalone, and other launch contexts.
  - Stores package-layout paths as `AbsolutePathBuf` values.
  - Keeps `codex-resources/` and `codex-path/` optional so Codex can still
  run with degraded behavior if sidecar directories are missing.
  - Updates `InstallContext::rg_command()` to prefer bundled
  `codex-path/rg` or `rg.exe`, then fall back to the legacy standalone
  resources location, then system `rg`.
  - Updates `codex doctor` reporting so package installs show package,
  bin, resources, and path directories, and so bundled search detection
  recognizes `codex-path/` for any install method.
  
  ## Test plan
  
  - `cargo test -p codex-install-context`
  - `cargo test -p codex-cli`
  - `cargo test -p codex-tui
  update_action::tests::maps_install_context_to_update_action`
  - `just bazel-lock-check`

  Michael Bolin · 2026-05-19 23:13:49 -07:00
  cfa16fcc2e
• ci: build Codex package archives in release workflow (#23582)

  ## Why
  
  Release CI already builds the Codex entrypoints before staging
  artifacts, and the package builder can now package those prebuilt
  binaries directly. The workflow should produce package-shaped sidecar
  archives from the same staged entrypoints that downstream distribution
  channels will eventually consume, without rebuilding `codex` or
  `codex-app-server` inside the packaging step.
  
  This intentionally does **not** publish the new package archives as
  GitHub Release assets yet. The archives are kept with workflow artifacts
  until npm, Homebrew, `install.sh`, winget, and related consumers are
  ready to switch over.
  
  ## What changed
  
  - Adds a `Build Codex package archive` step to
  `.github/workflows/rust-release.yml` after target artifacts are staged.
  - Runs `scripts/build_codex_package.py` for both release bundles:
  - `primary` builds `codex-package-${TARGET}.tar.gz` with `--variant
  codex`.
  - `app-server` builds `codex-app-server-package-${TARGET}.tar.gz` with
  `--variant codex-app-server`.
  - Passes `--entrypoint-bin target/${TARGET}/release/<entrypoint>` so
  packages contain the entrypoint already built by the workflow.
  - Deletes both package archive names before the final GitHub Release
  upload so they remain workflow artifacts only for now.
  
  ## Verification
  
  - Parsed `.github/workflows/rust-release.yml` with Ruby's YAML loader.
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23582).
  * #23596
  * __->__ #23582

  Michael Bolin · 2026-05-20 05:43:53 +00:00
  57a68fb9e3
• build: package prebuilt Codex entrypoints (#23586)

  ## Why
  
  The package builder should describe the binaries it is actually
  packaging, not require callers to restate release metadata out of band.
  A caller-provided `--version` flag can drift from the workspace version,
  but running the target entrypoint to discover its version breaks
  cross-target packages when the produced binary cannot execute on the
  build host.
  
  This PR keeps package metadata tied to the repository source of truth by
  reading `[workspace.package].version` from `codex-rs/Cargo.toml`. It
  also prepares the package layout for `codex-app-server` packages: the
  same package structure can now represent either the CLI entrypoint or
  the app-server entrypoint while keeping shared sidecars such as `rg`,
  `bwrap`, and Windows sandbox helpers in the existing package
  directories.
  
  ## What changed
  
  - Removes the `--version` CLI flag from
  `scripts/build_codex_package.py`.
  - Adds Cargo.toml version discovery for `codex-package.json.version` via
  `codex-rs/Cargo.toml`.
  - Adds `--entrypoint-bin` so callers can package a prebuilt entrypoint
  instead of rebuilding it with Cargo.
  - Makes `--variant` an explicit choice between `codex` and
  `codex-app-server`, and uses it to select the cargo binary and packaged
  `bin/` entrypoint name.
  - Updates `scripts/codex_package/README.md` to document variants,
  prebuilt entrypoints, and Cargo.toml version detection.
  
  ## Verification
  
  - Compiled `scripts/build_codex_package.py` and
  `scripts/codex_package/*.py` with `PYTHONDONTWRITEBYTECODE=1`.
  - Ran `scripts/build_codex_package.py --help` and verified `--version`
  is gone while `--variant` and `--entrypoint-bin` are present.
  - Verified the package builder reads version `0.0.0` from
  `codex-rs/Cargo.toml`.
  - Built a fake cross-target `codex-app-server` package using a
  non-executable `--entrypoint-bin`; verified metadata records version
  `0.0.0`, variant `codex-app-server`, and `bin/codex-app-server` as the
  entrypoint.

  Michael Bolin · 2026-05-19 22:10:03 -07:00
  343a74076f
• feat: Add vertical remote plugin collection support (#23584)

  - Adds an explicit vertical marketplace kind for plugin/list that
  fail-open fetches collection=vertical only when full remote plugins are
  disabled.
  
  - Renames the global remote marketplace/cache identity to
  openai-curated-remote and materializes remote installs with backend
  release versions and app manifests.

  xl-openai · 2026-05-19 22:03:08 -07:00
  dc255b0d8a
• Warn on invalid UTF-8 in AGENTS.md files (#23232)

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

  Eric Traut · 2026-05-19 21:56:46 -07:00
  9dda71dbae
• [codex] Preserve raw code-mode exec output by default (#23564)

  ## Why
  Code mode can use nested unified exec calls as data sources. When those
  calls omit `max_output_tokens`, code mode should receive raw command
  output so the script can parse or summarize it itself. When code mode
  does provide `max_output_tokens`, that explicit nested budget should be
  respected, including values above the default unified exec limit, rather
  than being capped before code mode sees the result.
  
  ## What
  - Preserve direct unified exec truncation behavior, while letting
  code-mode exec/write_stdin keep `max_output_tokens` as `None` unless
  explicitly supplied.
  - Make code-mode tool results use raw output when no explicit limit is
  present, and use the explicit nested limit directly when one is
  specified.
  - Refactor unified exec output formatting so `truncated_output` takes
  the caller-selected token budget.
  - Add e2e integration coverage for explicit nested exec limits, omitted
  nested exec limits, outer exec limit propagation, omitted-limit outputs
  that exceed both the default and a small truncation policy, explicit
  nested limits above those caps, and high explicit limits that still
  compact larger command output.
  - Reuse the code-mode turn setup helper while directly asserting the
  exact exec output item in each test.
  
  ## Testing
  - `just fmt`
  - `git diff --check`
  - Not run locally per repo guidance; CI should validate the e2e
  integration tests.

  Ahmed Ibrahim · 2026-05-20 04:02:14 +00:00
  5a4202ad90
• Fix stale background terminal poll events (#23231)

  ## Why
  
  Issue #23214 reports `/ps` showing no background terminals while the
  status line still says it is waiting for a background terminal. The race
  is in core: `write_stdin` can poll a process that exits before the
  response returns. The process manager correctly returns `process_id:
  None`, but the handler still emitted a `TerminalInteraction` event using
  the requested session id, causing clients to believe a dead process was
  still being polled.
  
  Fixes #23214.
  
  ## What changed
  
  - Suppress `TerminalInteraction` events for empty `write_stdin` polls
  once `response.process_id` is `None`.
  - Continue emitting interactions for non-empty stdin, even if that input
  causes the process to exit before the response returns.
  - Extend the unified exec integration test to assert completed empty
  polls do not emit terminal interactions.
  
  ## Verification
  
  - `cargo test -p codex-core --test all
  unified_exec_emits_one_begin_and_one_end_event`
  - `cargo test -p codex-core --test all
  unified_exec_emits_terminal_interaction_for_write_stdin`
  
  `cargo test -p codex-core` currently aborts in unrelated
  `agent::control::tests::resume_agent_from_rollout_uses_edge_data_when_descendant_metadata_source_is_stale`
  with a reproducible stack overflow.

  Eric Traut · 2026-05-19 20:48:37 -07:00
  e43a2e297f
• Move plugin and skill warmup into session startup (#23535)

  ## Why
  
  Plugin and skill loading is useful as warmup and early validation, but
  session startup does not need to wait for that work before it can
  continue building the session. Keeping it on the serial startup path
  adds avoidable latency to every fresh thread start.
  
  We still want invalid skill configurations to show up quickly, and we
  want the warmup to exercise the same plugin and skill manager caches
  that the normal turn path uses.
  
  ## What changed
  
  - moved plugin and skill warmup into the session startup async path
  instead of eagerly awaiting it on the serial setup path
  - kept the warmup using the session's resolved filesystem/environment
  context so skill loading still sees the right roots
  - preserved early skill-load error logging so broken skill
  configurations still surface during startup
  - left the per-turn plugin and skill loading path unchanged, so turns
  still use the normal cached managers
  
  ## Testing
  
  - Not run locally; relying on CI for validation.

  Ahmed Ibrahim · 2026-05-19 20:05:52 -07:00
  532b9c83ae
• feat: add permission profile list api (#23412)

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

  viyatb-oai · 2026-05-20 02:42:56 +00:00
  c3faea0b09
• feat: expose codex-app-server version flag (#23593)

  ## Why
  
  `codex-app-server` is published as a standalone release binary, so it
  should support the same basic version inspection behavior users expect
  from command-line tools. This is independent of package assembly:
  package metadata now comes from `codex-rs/Cargo.toml`, but the
  standalone app-server binary should still answer `--version` directly.
  
  ## What changed
  
  - Enables Clap's generated `--version` flag for the `codex-app-server`
  binary by adding `#[command(version)]` to its top-level parser.
  
  ## Verification
  
  - Ran `cargo run -p codex-app-server --bin codex-app-server --
  --version` and verified it prints `codex-app-server 0.0.0`.

  Michael Bolin · 2026-05-19 19:01:05 -07:00
  1495302347
• Fan out rust-ci-full nextest by platform (#23358)

  ## Why
  
  `rust-ci-full` was paying the full Cargo nextest build-and-run cost once
  per platform, with Windows ARM64 as the long pole. This change moves the
  heavy work into one reusable per-platform flow: build a nextest archive
  once, then replay it across four shards so the platform lane spends less
  time running tests serially. For Windows ARM64, the archive is
  cross-compiled on Windows x64 and replayed on native Windows ARM64
  shards so the slow ARM64 machine is used for execution rather than
  compilation.
  
  ## What changed
  
  - split the `rust-ci-full` nextest matrix into five explicit
  per-platform reusable-workflow calls
  - add `.github/workflows/rust-ci-full-nextest-platform.yml` to build one
  archive, upload timings/helpers, replay four nextest shards, upload
  per-shard JUnit, and roll the shard status back up per platform
  - add Windows CI helpers for Dev Drive setup and MSVC ARM64 linker
  environment export so the Windows ARM64 archive can be produced on
  Windows x64
  - keep the existing Cargo git CLI fetch hardening inside the reusable
  workflow, since caller workflow-level `env` does not flow through
  `workflow_call`
  - document the archive-backed shard shape in
  `.github/workflows/README.md`
  - raise the default nextest slow timeout to 30s so the sharded full-CI
  path does not treat every >15s test as stuck
  
  ## Verification
  
  - validated the archive/shard flow with live GitHub Actions runs on this
  PR branch
  - Windows ARM64 cross-compile latency on completed runs:
  - https://github.com/openai/codex/actions/runs/26118759651: `34m30s`
  lane e2e, `17m16s` archive build, `9m55s` shard phase
  - https://github.com/openai/codex/actions/runs/26120777976: `30m36s`
  lane e2e, `17m21s` archive build, `6m50s` shard phase
  - comparable pre-cross-compile sharded Windows ARM64 runs were `55m01s`,
  `50m21s`, and `46m42s`, so the completed cross-compile runs improved the
  lane by roughly `12m` to `24m` versus the prior range
  - latest corrected cross-compile run:
  https://github.com/openai/codex/actions/runs/26120777976
    - Windows ARM64 archive built successfully on Windows x64
  - native Windows ARM64 shards started immediately after the archive
  upload
  - 3/4 Windows ARM64 shards passed; the failing shard hit the same
  existing `code_mode` test failure seen outside this lane
  - downloaded failed-shard JUnit XML from the validation runs and
  confirmed the remaining red is from known test failures, not
  archive/shard wiring
  - no local Codex tests run per repo guidance
  
  ## Notes
  
  - this PR does not change developers.openai.com documentation

  starr-openai · 2026-05-19 17:54:41 -07:00
  64ef6cd1e4
• build: default Codex package target and output (#23541)

  ## Why
  
  The package builder should be easy to run during local iteration.
  Requiring callers to provide both a target triple and an output
  directory every time makes the common host-package case more awkward
  than necessary.
  
  This PR keeps explicit overrides available, but makes the default
  invocation useful: build for the current host platform and place the
  package in a fresh temporary directory. Because a temp output path is
  otherwise easy to lose, the builder continues to print the final package
  directory path when it completes.
  
  ## What changed
  
  - Makes `--target` optional and maps the host OS/architecture to
  supported Codex package target triples.
  - Uses GNU Linux target triples for Linux host defaults, while keeping
  the musl targets available for release jobs that pass `--target`
  explicitly.
  - Makes `--package-dir` optional and creates a new `codex-package-*`
  temp directory when omitted.
  - Documents the new defaults in `scripts/codex_package/README.md`.
  
  ## Verification
  
  - Compiled `scripts/build_codex_package.py` and
  `scripts/codex_package/*.py` with `PYTHONDONTWRITEBYTECODE=1`.
  - Ran `scripts/build_codex_package.py --help` from outside the repo.
  - Verified Linux host detection maps `x86_64` and `aarch64` to GNU
  target triples.
  - Ran a fake-Cargo package build while omitting both `--target` and
  `--package-dir`; verified the generated metadata target, expected
  package files, and printed temp package path.
  - Ran a fake-Cargo package build for `x86_64-unknown-linux-gnu` and
  verified `codex`, `bwrap`, and `rg` are assembled into the package.

  Michael Bolin · 2026-05-20 00:05:43 +00:00
  79f044ed34
• test: fix multi-agent service tier assertion (#23576)

  ## Why
  
  `openai/codex#22169` added a regression test that expects an invalid
  child `service_tier` to be rejected, but the test used
  `Result::expect_err` on `SpawnAgentHandler::handle`. That requires the
  `Ok` type to implement `Debug`, and this handler returns `Box<dyn
  ToolOutput>`, so Bazel failed while compiling `codex-core` tests before
  it could run them.
  
  ## What changed
  
  - Capture the handler result and assert on `result.err()` instead of
  calling `expect_err`.
  - Keep the same `FunctionCallError::RespondToModel` assertion for the
  rejected service tier.
  
  ## Verification
  
  - `cargo test -p codex-core
  spawn_agent_role_service_tier_does_not_hide_invalid_spawn_request`

  Michael Bolin · 2026-05-19 16:47:20 -07:00
  c58c84d6ee
• Remove unused ARC monitor path (#23573)

  ## Summary
  - remove the unreachable ARC monitor path from MCP tool approval
  handling
  - delete the unused ARC monitor module/tests and trim the orphaned
  safety-monitor decision plumbing
  - keep `always allow` approvals on the existing auto-approval
  short-circuit without a dead monitor hop
  
  ## Testing
  - `cargo test -p codex-core mcp_tool_call`
  - `just fmt`
  - `just fix -p codex-core`
  - `git diff --check`
  
  ## Additional validation
  - Attempted `cargo test -p codex-core`; the library test target passed,
  then the integration target failed in this local environment.
  - The narrower MCP-focused rerun passed its unit coverage and only hit
  missing local `test_stdio_server` binaries in filtered integration
  cases.

  Matthew Zeng · 2026-05-19 16:23:25 -07:00
  b019a678d8
• build: fetch rg for Codex packages (#23526)

  ## Why
  
  The Codex package builder should produce a complete package without
  requiring callers to pre-populate `rg` under `codex-cli/vendor` or have
  `dotslash` installed on `PATH`. The repo already tracks the
  authoritative DotSlash manifest in `codex-cli/bin/rg`, so the builder
  can read that metadata directly and fetch the correct ripgrep archive
  for the target it is packaging.
  
  ## What changed
  
  - Added `scripts/codex_package/ripgrep.py` to parse `codex-cli/bin/rg`
  after stripping the shebang, select the target platform entry, download
  the configured artifact, and verify the recorded size and SHA-256
  digest.
  - Added a cache under `$TMPDIR/codex-package/<target>-rg` so verified
  archives can be reused without fetching again.
  - Extracted `rg`/`rg.exe` from `tar.gz` and `zip` artifacts into the
  package-builder cache, then copied that into `codex-path` through the
  existing package layout flow.
  - Kept `--rg-bin` as an explicit local override for offline tests and
  unusual local workflows.
  - Documented the default `rg` fetch/cache behavior in
  `scripts/codex_package/README.md`.
  
  ## Verification
  
  - Ran wrapper/module syntax compilation.
  - Ran `scripts/build_codex_package.py --help` from `/private/tmp`.
  - Ran a local manifest fetch test covering shebang-stripped manifest
  parsing, `tar.gz` extraction, `zip` extraction, size/SHA-256
  verification, and cache reuse after deleting the original source
  archives.
  - Ran fake-cargo package/archive builds for macOS, Linux, and Windows
  target layouts with `--rg-bin`, including an assertion that generated
  tar archives contain no duplicate member names.
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23526).
  * #23541
  * __->__ #23526

  Michael Bolin · 2026-05-19 15:52:17 -07:00
  59f262a2b4
• Fix: TUI starting in wrong CWD (#23538)

  This fixes a regression wher codex could start in the wrong directory
  when a live local app-server socket was present. The issue was that
  implicit local socket reuse was being treated like an explicit remote
  workspace session, which dropped the invoking cwd unless --cd was
  passed.
  
  The change separates local socket transport from true remote workspace
  semantics.
  - Plain local startup keeps local cwd, trust, resume, picker, and
  config-refresh behavior.
  - Explicit --remote keeps the existing remote cwd behavior.
  - Added coverage for launch target selection and local-session
  filtering/cwd behavior.
  
  Steps to test:
  - Start a local app-server from a different directory than the repo you
  want to use.
    - Launch codex from a project/worktree without --cd.
  - Confirm the session starts in the invoking directory, not the
  app-server process directory.
  - Confirm explicit codex --remote ... still preserves existing remote
  behavior.

  canvrno-oai · 2026-05-19 15:48:40 -07:00
  27c4c67b15
• Add CUA requirements subsection for locked computer use (#23555)

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

  adams-oai · 2026-05-19 15:41:44 -07:00
  d86352d520
• [codex] Honor role-defined spawn service tiers (#22169)

  ## Why
  Custom agent roles are ordinary config layers, so a role file can
  already express `service_tier` just like other config values. The
  spawned-agent tier path needs to preserve that effective role config and
  follow the same precedence pattern as model/reasoning.
  
  ## What changed
  - Apply an explicit spawn-time `service_tier` onto the child config
  before role application, so a role config layer can override it just
  like role-defined model/reasoning settings do.
  - Validate the final effective child tier after the final child model is
  known, while still falling back to the parent tier when no child tier
  survives.
  - Add focused integration coverage for both v1 and v2 proving role TOML
  loads a service tier, spawned children keep that role-configured tier,
  and a role tier wins over a conflicting spawn-time tier.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - Local Rust tests not run, per repo guidance; CI should exercise the
  new coverage.

  Ahmed Ibrahim · 2026-05-19 22:40:41 +00:00
  c53da029bc
• fix: serialize unix app-server startup (#23516)

  # Summary
  
  Unix-socket app-server startup can currently race when multiple launch
  attempts target the same `CODEX_HOME`. Those processes can overlap
  before the control socket exists, which lets them enter SQLite state
  initialization concurrently and reproduce the startup corruption pattern
  seen in SSH mode.
  
  This change makes the app-server own that singleton startup guarantee.
  Unix-socket startup now takes a `CODEX_HOME`-scoped advisory lock before
  SQLite initialization, runs the existing control-socket preparation
  check while holding that lock, returns the established `AddrInUse` error
  when another live listener already owns the socket, and releases the
  lock once the new listener has bound its socket.
  
  # Design decisions
  
  - The singleton rule lives in `app-server --listen unix://`, not in a
  desktop-only caller path, so every Unix-socket launch gets the same race
  protection.
  - A duplicate raw app-server launch returns an error instead of silently
  succeeding. The attach operation remains `app-server proxy`, which
  continues to connect to an already-running listener.
  - The lock is held only across the dangerous startup window: socket
  preparation, SQLite initialization, and socket bind. It is not held for
  the app-server lifetime.
  - Listener detection stays in `prepare_control_socket_path(...)`, so the
  preexisting live-listener and stale-socket behavior remains the single
  source of truth.
  
  # Testing
  
  Tests: targeted Unix-socket transport tests on the branch checkout, full
  `codex-cli` build on `efrazer-db10`, and an SSH-style smoke on
  `efrazer-db10` covering concurrent app-server starts, explicit
  duplicate-start errors, and absence of SQLite startup-error matches in
  launch logs.

  efrazer-oai · 2026-05-19 14:57:11 -07:00
  c2141c7ce0
• Split plugin install discovery into list and request tools (#23372)

  ## Summary
  - Add `list_available_plugins_to_install` as the inventory step for
  plugin and connector install suggestions.
  - Slim `request_plugin_install` so it only handles the actual
  elicitation, instead of carrying the full discoverable list in its
  prompt.
  - Emit send-time telemetry when an install elicitation is dispatched,
  including requested tool identity in the event payload.
  - Emit install-result telemetry through `SessionTelemetry`, including
  tool type, user response action, and completion status.
  - Update registration and tests to cover the new two-step flow while
  keeping the existing `tool_suggest` feature gate unchanged.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core request_plugin_install`
  - `cargo test -p codex-core list_available_plugins_to_install`
  - `cargo test -p codex-core
  install_suggestion_tools_can_be_registered_without_search_tool`
  - `cargo test -p codex-otel
  manager_records_plugin_install_suggestion_metric`
  - `cargo test -p codex-otel
  manager_records_plugin_install_elicitation_sent_metric`
  - `just fix -p codex-core`
  - `just fix -p codex-tools`
  - `just fix -p codex-otel`
  - `cargo check -p codex-core`

  Matthew Zeng · 2026-05-19 14:45:37 -07:00
  8335b56c33
• Route local-only app-server gating through processors (#23551)

  ## Summary
  - move local-only app-server gating out of `MessageProcessor`
  - let `fs/*`, `command/exec`, and `process/spawn` resolve local
  availability inside their owning processors
  - keep `fs/*` mounted for the future environment-param path while
  preserving current no-local error behavior
  
  ## Validation
  - not run locally per Codex repo guidance

  starr-openai · 2026-05-19 14:38:03 -07:00
  1509ae6d8d
• Fix empty rollout path app-server handling (#23400)

  ## Summary
  - Coerce `path: ""` to `None` at the v2 protocol params deserialization
  boundary for `thread/resume` and `thread/fork`.
  - Restore the pre-ThreadStore running-thread resume behavior: if
  `threadId` is already running, rejoin it by id and treat a non-empty
  `path` only as a consistency check; otherwise cold resume keeps `history
  > path > threadId` precedence.
  - Add protocol, resume, and fork regression coverage for empty path
  payloads; refresh app-server schema fixtures for the clarified params
  docs.
  
  ## Tests
  - `just fmt`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol
  thread_path_params_deserialize_empty_path_as_none`
  - `cargo test -p codex-app-server-protocol --test schema_fixtures`
  - `cargo test -p codex-app-server empty_path`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-app-server --test all
  thread_resume_rejects_mismatched_path_for_running_thread_id`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-app-server --test all
  thread_resume_uses_path_over_non_running_thread_id`

  Tom · 2026-05-19 21:19:38 +00:00
  954a9c8579
• fix(tui): preserve modified enter in plan questions (#23536)

  ## Why
  
  Plan mode questionnaires reuse the shared composer for free-form
  answers, but the surrounding `request_user_input` overlay still treated
  every `KeyCode::Enter` as “advance to the next question.” That made
  `Shift+Enter` insert a newline in the composer and then immediately
  advance the questionnaire anyway.
  
  Fixes #23448.
  
  ## What Changed
  
  - pass the live `RuntimeKeymap` into `RequestUserInputOverlay` so its
  embedded composer honors existing `/keymap` composer/editor remaps
  - advance free-form questions only on the configured composer submit
  binding, instead of any Enter-shaped key event
  - add regressions for `Shift+Enter` newline behavior and configured
  composer submit bindings inside the questionnaire UI
  
  ## How to Test
  
  1. Start Codex in Plan mode and trigger a `request_user_input`
  questionnaire with a free-form answer field.
  2. Focus the free-form field, type a line, then press `Shift+Enter`.
  3. Confirm the answer gains a newline and the questionnaire stays on the
  same question.
  4. Press the configured submit binding, or plain `Enter` with the
  default keymap, and confirm the questionnaire advances as before.
  
  Targeted tests:
  - `cargo test -p codex-tui
  bottom_pane::request_user_input::tests::freeform_ -- --nocapture`
  
  ## Notes
  
  - `cargo test -p codex-tui` still reaches an unrelated existing stack
  overflow in
  `app::tests::discard_side_thread_removes_agent_navigation_entry` on this
  checkout.
  - `just argument-comment-lint` is locally blocked by Bazel analysis
  failing in external `compiler-rt` before the lint runs.

  Felipe Coury · 2026-05-19 18:01:38 -03:00
  40be41763c
• Refactor exec-server websocket pump (#23327)

  ## Why
  Exec-server websocket handling had separate reader and writer tasks for
  the same socket. That made websocket control-frame handling asymmetric:
  the task reading frames could observe `Ping`, but the task allowed to
  write frames was elsewhere. This PR moves each physical websocket onto
  one always-running pump so the socket owner can handle application
  frames and websocket control frames together.
  
  ## What changed
  - Refactored direct exec-server websocket connections in `connection.rs`
  to use one task that owns the websocket for outbound JSON-RPC, inbound
  JSON-RPC, periodic keepalive pings, and `Ping` -> `Pong` replies.
  - Refactored relay websocket handling in `relay.rs` the same way for
  both the harness-side logical connection and the multiplexed executor
  physical socket.
  - Preserved the existing keepalive ownership policy: outbound direct
  websocket clients still send periodic pings, inbound Axum accepts only
  reply with pongs, and relay physical websocket endpoints keep their
  existing periodic pings.
  - Added focused websocket pump tests for ping/pong, binary JSON-RPC,
  relay data, malformed relay text frames, and close/disconnect behavior.
  - Reconnect behavior is intentionally left for a follow-up.
  
  ## Validation
  - Devbox Bazel focused unit target:
  - `//codex-rs/exec-server:exec-server-unit-tests
  --test_filter='websocket_connection_|harness_connection_|multiplexed_executor_'`

  starr-openai · 2026-05-19 13:31:57 -07:00
  83af3abc68
• Make local environment optional in EnvironmentManager (#23369)

  ## Summary
  - make `EnvironmentManager` local environment/runtime paths optional
  - simplify constructor surface around snapshot materialization
  - rename local env accessors to `require_local_environment` /
  `try_local_environment`
  
  ## Validation
  - devbox Bazel build for touched crate surfaces
  - `//codex-rs/exec-server:exec-server-unit-tests`
  - `//codex-rs/app-server-client:app-server-client-unit-tests`
  - filtered touched `//codex-rs/core:core-unit-tests` cases

  starr-openai · 2026-05-19 12:55:34 -07:00
  5c43a64e2b