205 Commits

• feat: add service name to app-server (#12319)

  Add service name to the app-server so that the app can use it's own
  service name
  
  This is on thread level because later we might plan the app-server to
  become a singleton on the computer

  jif-oai · 2026-02-25 09:51:42 +00:00
  10c04e11b8
• feat: pass helper executable paths via Arg0DispatchPaths (#12719)

  ## Why
  
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs` previously
  located `codex-execve-wrapper` by scanning `PATH` and sibling
  directories. That lookup is brittle and can select the wrong binary when
  the runtime environment differs from startup assumptions.
  
  We already pass `codex-linux-sandbox` from `codex-arg0`;
  `codex-execve-wrapper` should use the same startup-driven path plumbing.
  
  ## What changed
  
  - Introduced `Arg0DispatchPaths` in `codex-arg0` to carry both helper
  executable paths:
    - `codex_linux_sandbox_exe`
    - `main_execve_wrapper_exe`
  - Updated `arg0_dispatch_or_else()` to pass `Arg0DispatchPaths` to
  top-level binaries and preserve helper paths created in
  `prepend_path_entry_for_codex_aliases()`.
  - Threaded `Arg0DispatchPaths` through entrypoints in `cli`, `exec`,
  `tui`, `app-server`, and `mcp-server`.
  - Added `main_execve_wrapper_exe` to core configuration plumbing
  (`Config`, `ConfigOverrides`, and `SessionServices`).
  - Updated zsh-fork shell escalation to consume the configured
  `main_execve_wrapper_exe` and removed path-sniffing fallback logic.
  - Updated app-server config reload paths so reloaded configs keep the
  same startup-provided helper executable paths.
  
  ## References
  
  - [`Arg0DispatchPaths`
  definition](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/arg0/src/lib.rs#L20-L24)
  - [`arg0_dispatch_or_else()` forwarding both
  paths](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/arg0/src/lib.rs#L145-L176)
  - [zsh-fork escalation using configured wrapper
  path](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs#L109-L150)
  
  ## Testing
  
  - `cargo check -p codex-arg0 -p codex-core -p codex-exec -p codex-tui -p
  codex-mcp-server -p codex-app-server`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core tools::runtimes::shell::unix_escalation:: --
  --nocapture`

  Michael Bolin · 2026-02-24 17:44:38 -08:00
  e88f74d140
• fix: clarify the value of SkillMetadata.path (#12729)

  Rename `SkillMetadata.path` to `SkillMetadata.path_to_skills_md` for
  clarity.
  
  Would ideally change the type to `AbsolutePathBuf`, but that can be done
  later.

  Michael Bolin · 2026-02-24 17:15:54 -08:00
  448fb6ac22
• codex-rs/app-server: graceful websocket restart on Ctrl-C (#12517)

  ## Summary
  - add graceful websocket app-server restart on Ctrl-C by draining until
  no assistant turns are running
  - stop the websocket acceptor and disconnect existing connections once
  the drain condition is met
  - add a websocket integration test that verifies Ctrl-C waits for an
  in-flight turn before exit
  
  ## Verification
  - `cargo check -p codex-app-server --quiet`
  - `cargo test -p codex-app-server --test all
  suite::v2::connection_handling_websocket`
  - I (maxj) tested remote and local Codex.app
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Max Johnson · 2026-02-24 16:27:59 -08:00
  5163850025
• Add app-server event tracing (#12695)

  To help with debugging

  pakrym-oai · 2026-02-24 14:45:50 -08:00
  5571a022eb
• Ensure shell command skills trigger approval (#12697)

  Summary
  - detect skill-invoking shell commands based on the original command
  string, request approvals when needed, and cache positive decisions per
  session
  - keep implicit skill invocation emitted after approval and keep skill
  approval decline messaging centralized to the shell handler
  - expand and adjust skill approval tests to cover shell-based skill
  scripts while matching the new detection expectations
  
  Testing
  - Not run (not requested)

  pakrym-oai · 2026-02-24 12:13:20 -08:00
  daf0f03ac8
• app-server: retain thread listener across disconnects (#12373)

  - keep the per-thread app-server listener alive when the last client
  unsubscribes or disconnects
  - preserve listener-side active turn history so running `thread/resume`
  can merge an in-progress turn snapshot after reconnect
  - add `ThreadStateManager` regressions for disconnect/unsubscribe
  retention and explicit thread teardown cleanup
  
  Added unit tests, and I manually tested to confirm the fix
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Max Johnson · 2026-02-22 05:33:33 +00:00
  37610240ec
• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• fix: address flakiness in thread_resume_rejoins_running_thread_even_with_override_mismatch (#12381)

  ## Why
  `thread/resume` responses for already-running threads can be reported as
  `Idle` even while a turn is still in progress. This is caused by a
  timing window where the runtime watch state has not yet observed the
  running-thread transition, so API clients can receive stale status
  information at resume time.
  
  Possibly related: https://github.com/openai/codex/pull/11786
  
  ## What
  - Add a shared status normalization helper, `resolve_thread_status`, in
  `codex-rs/app-server/src/thread_status.rs` that resolves
  `Idle`/`NotLoaded` to `Active { active_flags: [] }` when an in-progress
  turn is known.
  - Reuse this helper across thread response paths in
  `codex-rs/app-server/src/codex_message_processor.rs` (including
  `thread/start`, `thread/unarchive`, `thread/read`, `thread/resume`,
  `thread/fork`, and review/thread-started notification responses).
  - In `handle_pending_thread_resume_request`, use both the in-memory
  `active_turn_snapshot` and the resumed rollout turns to decide whether a
  turn is in progress before resolving thread status for the response.
  - Extend `thread_status` tests to validate the new status-resolution
  behavior directly.
  
  ## Verification
  - `cargo test -p codex-app-server
  suite::v2::thread_resume::thread_resume_rejoins_running_thread_even_with_override_mismatch`

  Michael Bolin · 2026-02-20 20:36:04 -08:00
  a73efab8dd
• Add field to Thread object for the latest rename set for a given thread (#12301)

  Exposes through the app server updated names set for a thread. This
  enables other surfaces to use the core as the source of truth for thread
  naming. `threadName` is gathered using the helper functions used to
  interact with `session_index.jsonl`, and is hydrated in:
  - `thread/list`
  - `thread/read`
  - `thread/resume`
  - `thread/unarchive`
  - `thread/rollback`
  
  We don't do this for `thread/start` and `thread/fork`.

  natea-oai · 2026-02-20 18:26:57 -08:00
  936e744c93
• Add ability to attach extra files to feedback (#12370)

  Allow clients to provide extra files.

  pakrym-oai · 2026-02-20 22:26:14 +00:00
  1bb7989b20
• app-server: harden disconnect cleanup paths (#12218)

  Hardens codex-rs/app-server connection lifecycle and outbound routing
  for websocket clients. Fixes some FUD I was having
  
  - Added per-connection disconnect signaling (CancellationToken) for
  websocket transports.
  - Split websocket handling into independent inbound/outbound tasks
  coordinated by cancellation.
  - Changed outbound routing so websocket connections use non-blocking
  try_send; slow/full websocket writers are disconnected instead of
  stalling broadcast delivery.
  - Kept stdio behavior blocking-on-send (no forced disconnect) so local
  stdio clients are not dropped when queues are temporarily full.
  - Simplified outbound router flow by removing deferred
  pending_closed_connections handling.
  - Added guards to drop incoming response/notification/error messages
  from unknown connections.
  - Fixed listener teardown race in thread listener tasks using a
  listener_generation check so stale tasks do not clear newer listeners.
  
  Fixes
  https://linear.app/openai/issue/CODEX-4966/multiclient-handle-slow-notification-consumers
  
    ## Tests
  
    Added/updated transport tests covering:
  
    - broadcast does not block on a slow/full websocket connection
    - stdio connection waits instead of disconnecting on full queue
  
  I (maxj) have tested manually and will retest before landing

  Max Johnson · 2026-02-20 20:35:16 +00:00
  6b1091fc92
• Refactor network approvals to host/protocol/port scope (#12140)

  ## Summary
  Simplify network approvals by removing per-attempt proxy correlation and
  moving to session-level approval dedupe keyed by (host, protocol, port).
  Instead of encoding attempt IDs into proxy credentials/URLs, we now
  treat approvals as a destination policy decision.
  
  - Concurrent calls to the same destination share one approval prompt.
  - Different destinations (or same host on different ports) get separate
  prompts.
  - Allow once approves the current queued request group only.
  - Allow for session caches that (host, protocol, port) and auto-allows
  future matching requests.
  - Never policy continues to deny without prompting.
  
  Example:
  - 3 calls: 
    - a.com (line 443)
    - b.com (line 443)
    - a.com (line 443)
  => 2 prompts total (a, b), second a waits on the first decision.
  - a.com:80 is treated separately from a.com line 443
  
  ## Testing
  - `just fmt` (in `codex-rs`)
  - `cargo test -p codex-core tools::network_approval::tests`
  - `cargo test -p codex-core` (unit tests pass; existing
  integration-suite failures remain in this environment)

  viyatb-oai · 2026-02-20 10:39:55 -08:00
  e8afaed502
• fix: nick name at thread/read (#12347)
  jif-oai · 2026-02-20 17:53:51 +00:00
  035c4c30bb
• feat: add nick name to sub-agents (#12320)

  Adding random nick name to sub-agents. Used for UX
  
  At the same time, also storing and wiring the role of the sub-agent

  jif-oai · 2026-02-20 14:39:49 +00:00
  0f9eed3a6f
• app-server: improve thread resume rejoin flow (#11776)

  thread/resume response includes latest turn with all items, in band so
  no events are stale or lost
  
  Testing
  - e2e tested using app-server-test-client using flow described in
  "Testing Thread Rejoin Behavior" in
  codex-rs/app-server-test-client/README.md
  - e2e tested in codex desktop by reconnecting to a running turn

  Max Johnson · 2026-02-20 05:29:05 +00:00
  b06f91c4fe
• Add configurable MCP OAuth callback URL for MCP login (#11382)

  ## Summary
  
  Implements a configurable MCP OAuth callback URL override for `codex mcp
  login` and app-server OAuth login flows, including support for non-local
  callback endpoints (for example, devbox ingress URLs).
  
  ## What changed
  
  - Added new config key: `mcp_oauth_callback_url` in
  `~/.codex/config.toml`.
  - OAuth authorization now uses `mcp_oauth_callback_url` as
  `redirect_uri` when set.
  - Callback handling validates the callback path against the configured
  redirect URI path.
  - Listener bind behavior is now host-aware:
  - local callback URL hosts (`localhost`, `127.0.0.1`, `::1`) bind to
  `127.0.0.1`
    - non-local callback URL hosts bind to `0.0.0.0`
  - `mcp_oauth_callback_port` remains supported and is used for the
  listener port.
  - Wired through:
    - CLI MCP login flow
    - App-server MCP OAuth login flow
    - Skill dependency OAuth login flow
  - Updated config schema and config tests.
  
  ## Why
  
  Some environments need OAuth callbacks to land on a specific reachable
  URL (for example ingress in remote devboxes), not loopback. This change
  allows that while preserving local defaults for existing users.
  
  ## Backward compatibility
  
  - No behavior change when `mcp_oauth_callback_url` is unset.
  - Existing `mcp_oauth_callback_port` behavior remains intact.
  - Local callback flows continue binding to loopback by default.
  
  ## Testing
  
  - `cargo test -p codex-rmcp-client callback -- --nocapture`
  - `cargo test -p codex-core --lib mcp_oauth_callback -- --nocapture`
  - `cargo check -p codex-cli -p codex-app-server -p codex-rmcp-client`
  
  ## Example config
  
  ```toml
  mcp_oauth_callback_port = 5555
  mcp_oauth_callback_url = "https://<devbox>-<namespace>.gateway.<cluster>.internal.api.openai.org/callback"

  dkumar-oai · 2026-02-19 13:32:10 -08:00
  1070a0a712
• app-server: expose loaded thread status via read/list and notifications (#11786)

  Motivation
  - Today, a newly connected client has no direct way to determine the
  current runtime status of threads from read/list responses alone.
  - This forces clients to infer state from transient events, which can
  lead to stale or inconsistent UI when reconnecting or attaching late.
  
  Changes
  - Add `status` to `thread/read` responses.
  - Add `statuses` to `thread/list` responses.
  - Emit `thread/status/changed` notifications with `threadId` and the new
  status.
  - Track runtime status for all loaded threads and default unknown
  threads to `idle`.
  - Update protocol/docs/tests/schema fixtures for the revised API.
  
  Testing
  - Validated protocol API changes with automated protocol tests and
  regenerated schema/type fixtures.
  - Validated app-server behavior with unit and integration test suites,
  including status transitions and notifications.

  Ruslan Nigmatullin · 2026-02-18 15:20:03 -08:00
  1f54496c48
• app-server support for Windows sandbox setup. (#12025)

  app-server support for initiating Windows sandbox setup.
  server responds quickly to setup request and makes a future RPC call
  back to client when the setup finishes.
  
  The TUI implementation is unaffected but in a future PR I'll update the
  TUI to use the shared setup helper
  (`windows_sandbox.run_windows_sandbox_setup`)

  iceweasel-oai · 2026-02-18 13:03:16 -08:00
  292542616a
• app-server: Emit thread archive/unarchive notifications (#12030)

  * Add v2 server notifications `thread/archived` and `thread/unarchived`
  with a `threadId` payload.
  * Wire new events into `thread/archive` and `thread/unarchive` success
  paths.
  * Update app-server protocol/schema/docs accordingly.
  
  Testing:
  - Updated archive/unarchive end-to-end tests to verify both
  notifications are emitted with the expected thread id payload.

  Ruslan Nigmatullin · 2026-02-17 14:53:58 -08:00
  31cbebd3c2
• chore: rm remote models fflag (#11699)

  rm `remote_models` feature flag.
  
  We see issues like #11527 when a user has `remote_models` disabled, as
  we always use the default fallback `ModelInfo`. This causes issues with
  model performance.
  
  Builds on #11690, which helps by warning the user when they are using
  the default fallback. This PR will make that happen much less frequently
  as an accidental consequence of disabling `remote_models`.

  sayan-oai · 2026-02-17 11:43:16 -08:00
  41800fc876
• Add remote skill scope/product_surface/enabled params and cleanup (#11801)

  skills/remote/list: params=hazelnutScope, productSurface, enabled;
  returns=data: { id, name, description }[]
  skills/remote/export: params=hazelnutId; returns={ id, path }

  xl-openai · 2026-02-17 11:05:22 -08:00
  314029ffa3
• feat(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• fix: send unfiltered models over model/list (#11793)

  ### What
  to unblock filtering models in VSCE, change `model/list` app-server
  endpoint to send all models + visibility field `showInPicker` so
  filtering can be done in VSCE if desired.
  
  ### Tests
  Updated tests.

  sayan-oai · 2026-02-13 16:26:32 -08:00
  6b466df146
• codex-rs: fix thread resume rejoin semantics (#11756)

  ## Summary
  - always rejoin an in-memory running thread on `thread/resume`, even
  when overrides are present
  - reject `thread/resume` when `history` is provided for a running thread
  - reject `thread/resume` when `path` mismatches the running thread
  rollout path
  - warn (but do not fail) on override mismatches for running threads
  - add more `thread_resume` integration tests and fixes; including
  restart-based resume-with-overrides coverage
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server --test all thread_resume`
  - manual test with app-server-test-client
  https://github.com/openai/codex/pull/11755
  - manual test both stdio and websocket in app

  Max Johnson · 2026-02-13 23:09:58 +00:00
  fb0aaf94de
• [apps] Improve app listing filtering. (#11697)

  - [x] If an installed app is not on the app listing, remove it from the
  final list.

  Matthew Zeng · 2026-02-13 11:54:16 -08:00
  8468871e2b
• [apps] Fix app loading logic. (#11518)

  When `app/list` is called with `force_refetch=True`, we should seed the
  results with what is already cached instead of starting from an empty
  list. Otherwise when we send app/list/updated events, the client will
  first see an empty list of accessible apps and then get the updated one.

  Matthew Zeng · 2026-02-13 03:55:10 +00:00
  f93037f55d
• Add cwd as an optional field to thread/list (#11651)

  Add's the ability to filter app-server thread/list by cwd

  acrognale-oai · 2026-02-13 02:05:04 +00:00
  ebe359b876
• [apps] Add is_enabled to app info. (#11417)

  - [x] Add is_enabled to app info and the response of `app/list`.
  - [x] Update TUI to have Enable/Disable button on the app detail page.

  Matthew Zeng · 2026-02-13 00:30:52 +00:00
  c37560069a
• app-server: stabilize detached review start on Windows (#11646)

  ## Why
  
  `review_start_with_detached_delivery_returns_new_thread_id` has been
  failing on Windows CI. The failure mode is a process crash
  (`tokio-runtime-worker` stack overflow) during detached review setup,
  which causes EOF in the test harness.
  
  This test is intended to validate detached review thread identity, not
  shell snapshot behavior. We also still want detached review to avoid
  unnecessary rollout-path rediscovery when the parent thread is already
  loaded.
  
  ## What Changed
  
  - Updated detached review startup in
  `codex-rs/app-server/src/codex_message_processor.rs`:
    - `start_detached_review` now receives the loaded parent thread.
    - It prefers `parent_thread.rollout_path()`.
  - It falls back to `find_thread_path_by_id_str(...)` only if the
  in-memory path is unavailable.
  - Hardened the review test fixture in
  `codex-rs/app-server/tests/suite/v2/review.rs` by setting
  `shell_snapshot = false` in test config, so this test no longer depends
  on unrelated Windows PowerShell snapshot initialization.
  
  ## Verification
  
  - `cargo test -p codex-app-server`
  - Verified
  `suite::v2::review::review_start_with_detached_delivery_returns_new_thread_id`
  passes locally.
  
  ## Notes
  
  - Related context: rollout-path lookup behavior changed in #10532.

  Michael Bolin · 2026-02-12 16:12:44 -08:00
  2825ac85a8
• feat: introduce Permissions (#11633)

  ## Why
  We currently carry multiple permission-related concepts directly on
  `Config` for shell/unified-exec behavior (`approval_policy`,
  `sandbox_policy`, `network`, `shell_environment_policy`,
  `windows_sandbox_mode`).
  
  Consolidating these into one in-memory struct makes permission handling
  easier to reason about and sets up the next step: supporting named
  permission profiles (`[permissions.PROFILE_NAME]`) without changing
  behavior now.
  
  This change is mostly mechanical: it updates existing callsites to go
  through `config.permissions`, but it does not yet refactor those
  callsites to take a single `Permissions` value in places where multiple
  permission fields are still threaded separately.
  
  This PR intentionally **does not** change the on-disk `config.toml`
  format yet and keeps compatibility with legacy config keys.
  
  ## What Changed
  - Introduced `Permissions` in `core/src/config/mod.rs`.
  - Added `Config::permissions` and moved effective runtime permission
  fields under it:
    - `approval_policy`
    - `sandbox_policy`
    - `network`
    - `shell_environment_policy`
    - `windows_sandbox_mode`
  - Updated config loading/building so these effective values are still
  derived from the same existing config inputs and constraints.
  - Updated Windows sandbox helpers/resolution to read/write via
  `permissions`.
  - Threaded the new field through all permission consumers across core
  runtime, app-server, CLI/exec, TUI, and sandbox summary code.
  - Updated affected tests to reference `config.permissions.*`.
  - Renamed the struct/field from
  `EffectivePermissions`/`effective_permissions` to
  `Permissions`/`permissions` and aligned variable naming accordingly.
  
  ## Verification
  - `just fix -p codex-core -p codex-tui -p codex-cli -p codex-app-server
  -p codex-exec -p codex-utils-sandbox-summary`
  - `cargo build -p codex-core -p codex-tui -p codex-cli -p
  codex-app-server -p codex-exec -p codex-utils-sandbox-summary`

  Michael Bolin · 2026-02-12 14:42:54 -08:00
  a4cc1a4a85
• feat(app-server): experimental flag to persist extended history (#11227)

  This PR adds an experimental `persist_extended_history` bool flag to
  app-server thread APIs so rollout logs can retain a richer set of
  EventMsgs for non-lossy Thread > Turn > ThreadItems reconstruction (i.e.
  on `thread/resume`).
  
  ### Motivation
  Today, our rollout recorder only persists a small subset (e.g. user
  message, reasoning, assistant message) of `EventMsg` types, dropping a
  good number (like command exec, file change, etc.) that are important
  for reconstructing full item history for `thread/resume`, `thread/read`,
  and `thread/fork`.
  
  Some clients want to be able to resume a thread without lossiness. This
  lossiness is primarily a UI thing, since what the model sees are
  `ResponseItem` and not `EventMsg`.
  
  ### Approach
  This change introduces an opt-in `persist_full_history` flag to preserve
  those events when you start/resume/fork a thread (defaults to `false`).
  
  This is done by adding an `EventPersistenceMode` to the rollout
  recorder:
  - `Limited` (existing behavior, default)
  - `Extended` (new opt-in behavior)
  
  In `Extended` mode, persist additional `EventMsg` variants needed for
  non-lossy app-server `ThreadItem` reconstruction. We now store the
  following ThreadItems that we didn't before:
  - web search
  - command execution
  - patch/file changes
  - MCP tool calls
  - image view calls
  - collab tool outcomes
  - context compaction
  - review mode enter/exit
  
  For **command executions** in particular, we truncate the output using
  the existing `truncate_text` from core to store an upper bound of 10,000
  bytes, which is also the default value for truncating tool outputs shown
  to the model. This keeps the size of the rollout file and command
  execution items returned over the wire reasonable.
  
  And we also persist `EventMsg::Error` which we can now map back to the
  Turn's status and populates the Turn's error metadata.
  
  #### Updates to EventMsgs
  To truly make `thread/resume` non-lossy, we also needed to persist the
  `status` on `EventMsg::CommandExecutionEndEvent` and
  `EventMsg::PatchApplyEndEvent`. Previously it was not obvious whether a
  command failed or was declined (similar for apply_patch). These
  EventMsgs were never persisted before so I made it a required field.

  Owen Lin · 2026-02-12 19:34:22 +00:00
  efc8d45750
• app-server: add fuzzy search sessions for streaming file search (#10268)
  Jeremy Rose · 2026-02-12 10:49:44 -08:00
  66e0c3aaa3
• chore: drop mcp validation of dynamic tools (#11609)

  Drop validation of dynamic tools using MCP names to reduce latency

  jif-oai · 2026-02-12 17:15:25 +00:00
  ba6f7a9e15
• app-server: thread resume subscriptions (#11474)

  This stack layer makes app-server thread event delivery connection-aware
  so resumed/attached threads only emit notifications and approval prompts
  to subscribed connections.
  
  - Added per-thread subscription tracking in `ThreadState`
  (`subscribed_connections`) and mapped subscription ids to `(thread_id,
  connection_id)`.
  - Updated listener lifecycle so removing a subscription or closing a
  connection only removes that connection from the thread’s subscriber
  set; listener shutdown now happens when the last subscriber is gone.
  - Added `connection_closed(connection_id)` plumbing (`lib.rs` ->
  `message_processor.rs` -> `codex_message_processor.rs`) so disconnect
  cleanup happens immediately.
  - Scoped bespoke event handling outputs through `TargetedOutgoing` to
  send requests/notifications only to subscribed connections.
  - Kept existing threadresume behavior while aligning with the latest
  split-loop transport structure.

  Max Johnson · 2026-02-11 16:21:13 -08:00
  c0ecc2e1e1
• refactor: codex app-server ThreadState (#11419)

  this is a no-op functionality wise. consolidates thread-specific message
  processor / event handling state in ThreadState

  Max Johnson · 2026-02-11 12:20:54 -08:00
  b5339a591d
• Promote Windows Sandbox (#11341)

  1. Move Windows Sandbox NUX to right after trust directory screen
  2. Don't offer read-only as an option in Sandbox NUX.
  Elevated/Legacy/Quit
  3. Don't allow new untrusted directories. It's trust or quit
  4. move experimental sandbox features to `[windows]
  sandbox="elevated|unelevatd"`
  5. Copy tweaks = elevated -> default, non-elevated -> non-admin

  iceweasel-oai · 2026-02-11 11:48:33 -08:00
  87279de434
• Reapply "Add app-server transport layer with websocket support" (#11370)

  Reapply "Add app-server transport layer with websocket support" with
  additional fixes from https://github.com/openai/codex/pull/11313/changes
  to avoid deadlocking.
  
  This reverts commit 47356ff83c.
  
  ## Summary
  
  To avoid deadlocking when queues are full, we maintain separate tokio
  tasks dedicated to incoming vs outgoing event handling
  - split the app-server main loop into two tasks in
  `run_main_with_transport`
     - inbound handling (`transport_event_rx`)
     - outbound handling (`outgoing_rx` + `thread_created_rx`)
  - separate incoming and outgoing websocket tasks
  
  ## Validation
  
  Integration tests, testing thoroughly e2e in codex app w/ >10 concurrent
  requests
  
  <img width="1365" height="979" alt="Screenshot 2026-02-10 at 2 54 22 PM"
  src="https://github.com/user-attachments/assets/47ca2c13-f322-4e5c-bedd-25859cbdc45f"
  />
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Max Johnson · 2026-02-11 18:13:39 +00:00
  7053aa5457
• Cache cloud requirements (#11305)

  We're loading these from the web on every startup. This puts them in a
  local file with a 1hr TTL.
  
  We sign the downloaded requirements with a key compiled into the Codex
  CLI to prevent unsophisticated tampering (determined circumvention is
  outside of our threat model: after all, one could just compile Codex
  without any of these checks).
  
  If any of the following are true, we ignore the local cache and re-fetch
  from Cloud:
  * The signature is invalid for the payload (== requirements, sign time,
  ttl, user identity)
  * The identity does not match the auth'd user's identity
  * The TTL has expired
  * We cannot parse requirements.toml from the payload

  gt-oai · 2026-02-11 14:06:41 +00:00
  886d9377d3
• feat: support multiple rate limits (#11260)

  Added multi-limit support end-to-end by carrying limit_name in
  rate-limit snapshots and handling multiple buckets instead of only
  codex.
  Extended /usage client parsing to consume additional_rate_limits
  Updated TUI /status and in-memory state to store/render per-limit
  snapshots
  Extended app-server rate-limit read response: kept rate_limits and added
  rate_limits_by_name.
  Adjusted usage-limit error messaging for non-default codex limit buckets

  xl-openai · 2026-02-10 20:09:31 -08:00
  fdd0cd1de9
• chore: persist turn_id in rollout session and make turn_id uuid based (#11246)

  Problem:
  1. turn id is constructed in-memory;
  2. on resuming threads, turn_id might not be unique;
  3. client cannot no the boundary of a turn from rollout files easily.
  
  This PR does three things:
  1. persist `task_started` and `task_complete` events;
  1. persist `turn_id` in rollout turn events;
  5. generate turn_id as unique uuids instead of incrementing it in
  memory.
  
  This helps us resolve the issue of clients wanting to have unique turn
  ids for resuming a thread, and knowing the boundry of each turn in
  rollout files.
  
  example debug logs
  ```
  2026-02-11T00:32:10.746876Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=8 turn=Turn { id: "019c4a07-d809-74c3-bc4b-fd9618487b4b", items: [UserMessage { id: "item-24", content: [Text { text: "hi", text_elements: [] }] }, AgentMessage { id: "item-25", text: "Hi. I’m in the workspace with your current changes loaded and ready. Send the next task and I’ll execute it end-to-end." }], status: Completed, error: None }
  2026-02-11T00:32:10.746888Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=9 turn=Turn { id: "019c4a18-1004-76c0-a0fb-a77610f6a9b8", items: [UserMessage { id: "item-26", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-27", text: "Hello. Ready for the next change in `codex-rs`; I can continue from the current in-progress diff or start a new task." }], status: Completed, error: None }
  2026-02-11T00:32:10.746899Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=10 turn=Turn { id: "019c4a19-41f0-7db0-ad78-74f1503baeb8", items: [UserMessage { id: "item-28", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-29", text: "Hello. Send the specific change you want in `codex-rs`, and I’ll implement it and run the required checks." }], status: Completed, error: None }
  ```
  
  backward compatibility:
  if you try to resume an old session without task_started and
  task_complete event populated, the following happens:
  - If you resume and do nothing: those reconstructed historical IDs can
  differ next time you resume.
  - If you resume and send a new turn: the new turn gets a fresh UUID from
  live submission flow and is persisted, so that new turn’s ID is stable
  on later resumes.
  I think this behavior is fine, because we only care about deterministic
  turn id once a turn is triggered.

  Celia Chen · 2026-02-11 03:56:01 +00:00
  641d5268fa
• fix: reduce usage of open_if_present (#11344)
  jif-oai · 2026-02-10 19:25:07 +00:00
  847a6092e6
• Revert "Add app-server transport layer with websocket support (#10693)" (#11323)

  Suspected cause of deadlocking bug

  Max Johnson · 2026-02-10 17:37:49 +00:00
  47356ff83c
• feat: retain NetworkProxy, when appropriate (#11207)

  As of this PR, `SessionServices` retains a
  `Option<StartedNetworkProxy>`, if appropriate.
  
  Now the `network` field on `Config` is `Option<NetworkProxySpec>`
  instead of `Option<NetworkProxy>`.
  
  Over in `Session::new()`, we invoke `NetworkProxySpec::start_proxy()` to
  create the `StartedNetworkProxy`, which is a new struct that retains the
  `NetworkProxy` as well as the `NetworkProxyHandle`. (Note that `Drop` is
  implemented for `NetworkProxyHandle` to ensure the proxies are shutdown
  when it is dropped.)
  
  The `NetworkProxy` from the `StartedNetworkProxy` is threaded through to
  the appropriate places.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/11207).
  * #11285
  * __->__ #11207

  Michael Bolin · 2026-02-10 02:09:23 -08:00
  44ebf4588f
• [apps] Add thread_id param to optionally load thread config for apps feature check. (#11279)

  - [x] Add thread_id param to optionally load thread config for apps
  feature check

  Matthew Zeng · 2026-02-09 23:10:26 -08:00
  005e040f97
• fix(app-server): for external auth, replace id_token with chatgpt_acc… (#11240)

  …ount_id and chatgpt_plan_type
  
  ### Summary
  Following up on external auth mode which was introduced here:
  https://github.com/openai/codex/pull/10012
  
  Turns out some clients have a differently shaped ID token and don't have
  a chosen workspace (aka chatgpt_account_id) encoded in their ID token.
  So, let's replace `id_token` param with `chatgpt_account_id` and
  `chatgpt_plan_type` (optional) when initializing the external ChatGPT
  auth mode (`account/login/start` with `chatgptAuthTokens`).
  
  The client was able to test end-to-end with a Codex build from this
  branch and verified it worked!

  Owen Lin · 2026-02-09 20:48:58 -08:00
  53741013ab
• feat: extend skills/list to support additional roots. (#10835)

  Add an optional perCwdExtraUserRoots

  xl-openai · 2026-02-09 13:30:38 -08:00
  a33ee46e3b
• feat: do not close unified exec processes across turns (#10799)

  With this PR we do not close the unified exec processes (i.e. background
  terminals) at the end of a turn unless:
  * The user interrupt the turn
  * The user decide to clean the processes through `app-server` or
  `/clean`
  
  I made sure that `codex exec` correctly kill all the processes

  jif-oai · 2026-02-09 10:27:46 +00:00
  6cf61725d0
• feat: include NetworkConfig through ExecParams (#11105)

  This PR adds the following field to `Config`:
  
  ```rust
  pub network: Option<NetworkProxy>,
  ```
  
  Though for the moment, it will always be initialized as `None` (this
  will be addressed in a subsequent PR).
  
  This PR does the work to thread `network` through to `execute_exec_env()`, `process_exec_tool_call()`, and `UnifiedExecRuntime.run()` to ensure it is available whenever we span a process.

  Michael Bolin · 2026-02-09 03:32:17 +00:00
  383b45279e
• [apps] Improve app loading. (#10994)

  There are two concepts of apps that we load in the harness:
  
  - Directory apps, which is all the apps that the user can install.
  - Accessible apps, which is what the user actually installed and can be
  $ inserted and be used by the model. These are extracted from the tools
  that are loaded through the gateway MCP.
  
  Previously we wait for both sets of apps before returning the full apps
  list. Which causes many issues because accessible apps won't be
  available to the UI or the model if directory apps aren't loaded or
  failed to load.
  
  In this PR we are separating them so that accessible apps can be loaded
  separately and are instantly available to be shown in the UI and to be
  provided in model context. We also added an app-server event so that
  clients can subscribe to also get accessible apps without being blocked
  on the full app list.
  
  - [x] Separate accessible apps and directory apps loading.
  - [x] `app/list` request will also emit `app/list/updated` notifications
  that app-server clients can subscribe. Which allows clients to get
  accessible apps list to render in the $ menu without being blocked by
  directory apps.
  - [x] Cache both accessible and directory apps with 1 hour TTL to avoid
  reloading them when creating new threads.
  - [x] TUI improvements to redraw $ menu and /apps menu when app list is
  updated.

  Matthew Zeng · 2026-02-08 15:24:56 -08:00
  45b7763c3f