459 Commits

• app-server: Add ephemeral field to Thread object (#13084)

  Currently there is no alternative way to know that thread is ephemeral,
  only client which did create it has the knowledge.

  Ruslan Nigmatullin · 2026-02-27 17:42:25 -08:00
  8c1e3f3e64
• fix(app-server): make thread/start non-blocking (#13033)

  Stop `thread/start` from blocking other app-server requests.
  
  Before this change, `thread/start ran` inline on the request loop, so
  slow startup paths like MCP auth checks could hold up unrelated requests
  on the same connection, including `thread/loaded/list`. This moves
  `thread/start` into a background task.
  
  While doing so, it revealed an issue where we were doing nested locking
  (and there were some race conditions possible that could introduce a
  "phantom listener"). This PR also refactors the listener/subscription
  bookkeeping - listener/subscription state is now centralized in
  `ThreadStateManager` instead of being split across multiple lock
  domains. That makes late auto-attach on `thread/start` race-safe and
  avoids reintroducing disconnected clients as phantom subscribers.

  Owen Lin · 2026-02-28 01:40:08 +00:00
  8fa792868c
• Handle missing plan info for ChatGPT accounts (#13072)

  Addresses https://github.com/openai/codex/issues/13007 and
  https://github.com/openai/codex/issues/12170
  
  There are situations where the ChatGPT auth backend might return a JWT
  that contains no plan information. Most code paths already handle this
  case well, but the internal implementation of the "account/read" app
  server call was failing in this case (returning an error rather than
  properly returning None for the plan).
  
  This resulted in a situation where users needed to log in every time the
  extension or app started even if they successfully logged in the last
  time.
  
  Summary
  - allow ChatGPT-authenticated accounts to fall back to
  `AccountPlanType::Unknown` when the token omits the plan claim
  - add regression coverage in `app-server/tests/suite/v2/account.rs` to
  confirm `account/read` returns `plan_type: Unknown` when the claim is
  absent
  - ensure the Rust auth helpers and fixtures treat missing plan claims as
  Optional and default to `Unknown`

  Eric Traut · 2026-02-27 17:51:21 -07:00
  ff5cbfd7d4
• [apps] Stablize app list updated event. (#13067)

  Stablize app list updated event so that we only send 2 updates: 1 when
  installed apps become available, one when all directory apps are
  available. Previously it also updates when directory apps become
  available before installed apps, which cuts off installed apps.

  Matthew Zeng · 2026-02-27 15:23:24 -08:00
  392fa7de50
• app-server: Replay pending item requests on thread/resume (#12560)

  Replay pending client requests after `thread/resume` and emit resolved
  notifications when those requests clear so approval/input UI state stays
  in sync after reconnects and across subscribed clients.
  
  Affected RPCs:
  - `item/commandExecution/requestApproval`
  - `item/fileChange/requestApproval`
  - `item/tool/requestUserInput`
  
  Motivation:
  - Resumed clients need to see pending approval/input requests that were
  already outstanding before the reconnect.
  - Clients also need an explicit signal when a pending request resolves
  or is cleared so stale UI can be removed on turn start, completion, or
  interruption.
  
  Implementation notes:
  - Use pending client requests from `OutgoingMessageSender` in order to
  replay them after `thread/resume` attaches the connection, using
  original request ids.
  - Emit `serverRequest/resolved` when pending requests are answered
  or cleared by lifecycle cleanup.
  - Update the app-server protocol schema, generated TypeScript bindings,
  and README docs for the replay/resolution flow.
  
  High-level test plan:
  - Added automated coverage for replaying pending command execution and
  file change approval requests on `thread/resume`.
  - Added automated coverage for resolved notifications in command
  approval, file change approval, request_user_input, turn start, and turn
  interrupt flows.
  - Verified schema/docs updates in the relevant protocol and app-server
  tests.
  
  Manual testing:
  - Tested reconnect/resume with multiple connections.
  - Confirmed state stayed in sync between connections.

  Ruslan Nigmatullin · 2026-02-27 12:45:59 -08:00
  69d7a456bb
• app-server: deflake running thread resume tests (#13047)

  ## Why
  
  CI has been intermittently failing in
  `suite::v2::thread_resume::thread_resume_rejoins_running_thread_even_with_override_mismatch`
  because these running-thread resume tests treated `turn/started` as
  proof that the thread was already active.
  
  That signal is too early for this path. `turn/started` is emitted
  optimistically from
  [`turn_start`](https://github.com/openai/codex/blob/1103d0037e3bff798ed07b9e003b0cd360756ced/codex-rs/app-server/src/codex_message_processor.rs#L5757-L5767).
  In `single_client_mode`, the listener skips `current_turn_history`
  tracking in
  [`codex_message_processor.rs`](https://github.com/openai/codex/blob/1103d0037e3bff798ed07b9e003b0cd360756ced/codex-rs/app-server/src/codex_message_processor.rs#L6461-L6465),
  so running-thread resume still depends on `ThreadWatchManager` observing
  the core `TurnStarted` event in
  [`bespoke_event_handling.rs`](https://github.com/openai/codex/blob/1103d0037e3bff798ed07b9e003b0cd360756ced/codex-rs/app-server/src/bespoke_event_handling.rs#L152-L156).
  If `thread/resume` lands in that window, the thread can still look
  `Idle` and the assertion flakes.
  
  ## What
  
  - Add a helper in `codex-rs/app-server/tests/suite/v2/thread_resume.rs`
  that waits for `thread/status/changed` to report `Active` for the target
  thread.
  - Use that public v2 notification as the synchronization barrier in the
  four running-thread resume tests instead of relying on `turn/started`.
  
  ## Follow-up
  
  This PR keeps the fix at the test layer so we can remove the flake
  without changing server behavior. A broader runtime fix should still be
  considered separately, for example:
  
  - make `turn/start` eagerly transition the thread to `Active` so
  `turn/started` and `thread/status/changed` are coherent
  - or revisit the `single_client_mode` guard that skips current-turn
  tracking for running-thread resume
  
  ## Testing
  
  - `cargo test -p codex-app-server thread_resume -- --nocapture`
  - `for i in $(seq 1 10); do cargo test -p codex-app-server
  'suite::v2::thread_resume::thread_resume_rejoins_running_thread_even_with_override_mismatch'
  -- --exact --nocapture; done`

  Michael Bolin · 2026-02-27 19:47:30 +00:00
  66b0adb34c
• fix: use AbsolutePathBuf for permission profile file roots (#12970)

  ## Why
  `PermissionProfile` should describe filesystem roots as absolute paths
  at the type level. Using `PathBuf` in `FileSystemPermissions` made the
  shared type too permissive and blurred together three different
  deserialization cases:
  
  - skill metadata in `agents/openai.yaml`, where relative paths should
  resolve against the skill directory
  - app-server API payloads, where callers should have to send absolute
  paths
  - local tool-call payloads for commands like `shell_command` and
  `exec_command`, where `additional_permissions.file_system` may
  legitimately be relative to the command `workdir`
  
  This change tightens the shared model without regressing the existing
  local command flow.
  
  ## What Changed
  - changed `protocol::models::FileSystemPermissions` and the app-server
  `AdditionalFileSystemPermissions` mirror to use `AbsolutePathBuf`
  - wrapped skill metadata deserialization in `AbsolutePathBufGuard`, so
  relative permission roots in `agents/openai.yaml` resolve against the
  containing skill directory
  - kept app-server/API deserialization strict, so relative
  `additionalPermissions.fileSystem.*` paths are rejected at the boundary
  - restored cwd/workdir-relative deserialization for local tool-call
  payloads by parsing `shell`, `shell_command`, and `exec_command`
  arguments under an `AbsolutePathBufGuard` rooted at the resolved command
  working directory
  - simplified runtime additional-permission normalization so it only
  canonicalizes and deduplicates absolute roots instead of trying to
  recover relative ones later
  - updated the app-server schema fixtures, `app-server/README.md`, and
  the affected transport/TUI tests to match the final behavior

  Michael Bolin · 2026-02-27 17:42:52 +00:00
  d09a7535ed
• fix: more stable notify script (#13011)
  jif-oai · 2026-02-27 16:05:44 +01:00
  8cf5b00aef
• notify: include client in legacy hook payload (#12968)

  ## Why
  
  The `notify` hook payload did not identify which Codex client started
  the turn. That meant downstream notification hooks could not distinguish
  between completions coming from the TUI and completions coming from
  app-server clients such as VS Code or Xcode. Now that the Codex App
  provides its own desktop notifications, it would be nice to be able to
  filter those out.
  
  This change adds that context without changing the existing payload
  shape for callers that do not know the client name, and keeps the new
  end-to-end test cross-platform.
  
  ## What changed
  
  - added an optional top-level `client` field to the legacy `notify` JSON
  payload
  - threaded that value through `core` and `hooks`; the internal session
  and turn state now carries it as `app_server_client_name`
  - set the field to `codex-tui` for TUI turns
  - captured `initialize.clientInfo.name` in the app server and applied it
  to subsequent turns before dispatching hooks
  - replaced the notify integration test hook with a `python3` script so
  the test does not rely on Unix shell permissions or `bash`
  - documented the new field in `docs/config.md`
  
  ## Testing
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-app-server
  suite::v2::initialize::turn_start_notify_payload_includes_initialize_client_name
  -- --exact --nocapture`
  - `cargo test -p codex-core` (`src/lib.rs` passed; `core/tests/all.rs`
  still has unrelated existing failures in this environment)
  
  ## Docs
  
  The public config reference on `developers.openai.com/codex` should
  mention that the legacy `notify` payload may include a top-level
  `client` field. The TUI reports `codex-tui`, and the app server reports
  `initialize.clientInfo.name` when it is available.

  Michael Bolin · 2026-02-26 22:27:34 -08:00
  e6cd75a684
• Add model availability NUX metadata (#12972)

  - replace show_nux with structured availability_nux model metadata
  - expose availability NUX data through the app-server model API
  - update shared fixtures and tests for the new field

  Ahmed Ibrahim · 2026-02-26 22:02:57 -08:00
  4d180ae428
• Add oauth_resource handling for MCP login flows (#12866)

  Addresses bug https://github.com/openai/codex/issues/12589
  
  Builds on community PR #12763.
  
  This adds `oauth_resource` support for MCP `streamable_http` servers and
  wires it through the relevant config and login paths. It fixes the bug
  where the configured OAuth resource was not reliably included in the
  authorization request, causing MCP login to omit the expected
  `resource` parameter.

  Eric Traut · 2026-02-26 20:10:12 -08:00
  cee009d117
• [apps] Improve app/list with force_fetch=true (#12745)

  - [x] Improve app/list with force_fetch=true, we now keep cached
  snapshot until both install apps and directory apps load.

  Matthew Zeng · 2026-02-27 03:54:03 +00:00
  6fe3dc2e22
• Feat: cxa-1833 update model/list (#12958)

  ### Summary
  Update `model/list` in app server to include more upgrade information.

  Shijie Rao · 2026-02-26 17:02:24 -08:00
  8715a6ef84
• feat: add local date/timezone to turn environment context (#12947)

  ## Summary
  
  This PR includes the session's local date and timezone in the
  model-visible environment context and persists that data in
  `TurnContextItem`.
  
    ## What changed
  - captures the current local date and IANA timezone when building a turn
  context, with a UTC fallback if the timezone lookup fails
  - includes current_date and timezone in the serialized
  <environment_context> payload
  - stores those fields on TurnContextItem so they survive rollout/history
  handling, subagent review threads, and resume flows
  - treats date/timezone changes as environment updates, so prompt caching
  and context refresh logic do not silently reuse stale time context
  - updates tests to validate the new environment fields without depending
  on a single hardcoded environment-context string
  
  ## test
  
  built a local build and saw it in the rollout file:
  ```
  {"timestamp":"2026-02-26T21:39:50.737Z","type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":"<environment_context>\n  <shell>zsh</shell>\n  <current_date>2026-02-26</current_date>\n  <timezone>America/Los_Angeles</timezone>\n</environment_context>"}]}}
  ```

  Celia Chen · 2026-02-26 23:17:35 +00:00
  90cc4e79a2
• Allow clients not to send summary as an option (#12950)

  Summary is a required parameter on UserTurn. Ideally we'd like the core
  to decide the appropriate summary level.
  
  Make the summary optional and don't send it when not needed.

  pakrym-oai · 2026-02-26 14:37:38 -08:00
  951a389654
• Use model catalog default for reasoning summary fallback (#12873)

  ## Summary
  - make `Config.model_reasoning_summary` optional so unset means use
  model default
  - resolve the optional config value to a concrete summary when building
  `TurnContext`
  - add protocol support for `default_reasoning_summary` in model metadata
  
  ## Validation
  - `cargo test -p codex-core --lib client::tests -- --nocapture`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-02-26 09:31:13 -08:00
  ba41e84a50
• core: bundle settings diff updates into one dev/user envelope (#12417)

  ## Summary
  - bundle contextual prompt injection into at most one developer message
  plus one contextual user message in both:
    - per-turn settings updates
    - initial context insertion
  - preserve `<model_switch>` across compaction by rebuilding it through
  canonical initial-context injection, instead of relying on
  strip/reattach hacks
  - centralize contextual user fragment detection in one shared definition
  table and reuse it for parsing/compaction logic
  - keep `AGENTS.md` in its natural serialized format:
    - `# AGENTS.md instructions for {dirname}`
    - `<INSTRUCTIONS>...</INSTRUCTIONS>`
  - simplify related tests/helpers and accept the expected snapshot/layout
  updates from bundled multi-part messages
  
  ## Why
  The goal is to converge toward a simpler, more intentional prompt shape
  where contextual updates are consistently represented as one developer
  envelope plus one contextual user envelope, while keeping parsing and
  compaction behavior aligned with that representation.
  
  ## Notable details
  - the temporary `SettingsUpdateEnvelope` wrapper was removed; these
  paths now return `Vec<ResponseItem>` directly
  - local/remote compaction no longer rely on model-switch strip/restore
  helpers
  - contextual user detection is now driven by shared fragment definitions
  instead of ad hoc matcher assembly
  - AGENTS/user instructions are still the same logical context; only the
  synthetic `<user_instructions>` wrapper was replaced by the natural
  AGENTS text format
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-app-server
  codex_message_processor::tests::extract_conversation_summary_prefers_plain_user_messages
  -- --exact`
  - `cargo test -p codex-core
  compact::tests::collect_user_messages_filters_session_prefix_entries
  --lib -- --exact`
  - `cargo test -p codex-core --test all
  'suite::compact::snapshot_request_shape_pre_turn_compaction_strips_incoming_model_switch'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::compact_remote::snapshot_request_shape_remote_pre_turn_compaction_strips_incoming_model_switch'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_apps_guidance_as_developer_message_when_enabled'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_developer_instructions_message_in_request' --
  --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_user_instructions_message_in_request' --
  --exact`
  - `cargo test -p codex-core --test all
  'suite::client::resume_includes_initial_messages_and_sends_prior_items'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::review::review_input_isolated_from_parent_history' -- --exact`
  - `cargo test -p codex-exec --test all
  'suite::resume::exec_resume_last_respects_cwd_filter_and_all_flag' --
  --exact`
  - `cargo test -p core_test_support
  context_snapshot::tests::full_text_mode_preserves_unredacted_text --
  --exact`
  
  ## Notes
  - I also ran several targeted `compact`, `compact_remote`,
  `prompt_caching`, `model_visible_layout`, and `event_mapping` tests
  while iterating on prompt-shape changes.
  - I have not claimed a clean full-workspace `cargo test` from this
  environment because local sandbox/resource conditions have previously
  produced unrelated failures in large workspace runs.

  Charley Cunningham · 2026-02-26 00:12:08 -08:00
  07aefffb1f
• Enforce user input length cap (#12823)

  Currently there is no bound on the length of a user message submitted in
  the TUI or through the app server interface. That means users can paste
  many megabytes of text, which can lead to bad performance, hangs, and
  crashes. In extreme cases, it can lead to a [kernel
  panic](https://github.com/openai/codex/issues/12323).
  
  This PR limits the length of a user input to 2**20 (about 1M)
  characters. This value was chosen because it fills the entire context
  window on the latest models, so accepting longer inputs wouldn't make
  sense anyway.
  
  Summary
  - add a shared `MAX_USER_INPUT_TEXT_CHARS` constant in codex-protocol
  and surface it in TUI and app server code
  - block oversized submissions in the TUI submit flow and emit error
  history cells when validation fails
  - reject heavy app-server requests with JSON-RPC `-32602` and structured
  `input_too_large` data, plus document the behavior
  
  Testing
  - ran the IDE extension with this change and verified that when I
  attempt to paste a user message that's several MB long, it correctly
  reports an error instead of crashing or making my computer hot.

  Eric Traut · 2026-02-25 22:23:51 -08:00
  28bfbb8f2b
• feat: include available decisions in command approval requests (#12758)

  Command-approval clients currently infer which choices to show from
  side-channel fields like `networkApprovalContext`,
  `proposedExecpolicyAmendment`, and `additionalPermissions`. That makes
  the request shape harder to evolve, and it forces each client to
  replicate the server's heuristics instead of receiving the exact
  decision list for the prompt.
  
  This PR introduces a mapping between `CommandExecutionApprovalDecision`
  and `codex_protocol::protocol::ReviewDecision`:
  
  ```rust
  impl From<CoreReviewDecision> for CommandExecutionApprovalDecision {
      fn from(value: CoreReviewDecision) -> Self {
          match value {
              CoreReviewDecision::Approved => Self::Accept,
              CoreReviewDecision::ApprovedExecpolicyAmendment {
                  proposed_execpolicy_amendment,
              } => Self::AcceptWithExecpolicyAmendment {
                  execpolicy_amendment: proposed_execpolicy_amendment.into(),
              },
              CoreReviewDecision::ApprovedForSession => Self::AcceptForSession,
              CoreReviewDecision::NetworkPolicyAmendment {
                  network_policy_amendment,
              } => Self::ApplyNetworkPolicyAmendment {
                  network_policy_amendment: network_policy_amendment.into(),
              },
              CoreReviewDecision::Abort => Self::Cancel,
              CoreReviewDecision::Denied => Self::Decline,
          }
      }
  }
  ```
  
  And updates `CommandExecutionRequestApprovalParams` to have a new field:
  
  ```rust
  available_decisions: Option<Vec<CommandExecutionApprovalDecision>>
  ```
  
  when, if specified, should make it easier for clients to display an
  appropriate list of options in the UI.
  
  This makes it possible for `CoreShellActionProvider::prompt()` in
  `unix_escalation.rs` to specify the `Vec<ReviewDecision>` directly,
  adding support for `ApprovedForSession` when approving a skill script,
  which was previously missing in the TUI.
  
  Note this results in a significant change to `exec_options()` in
  `approval_overlay.rs`, as the displayed options are now derived from
  `available_decisions: &[ReviewDecision]`.
  
  ## What Changed
  
  - Add `available_decisions` to
  [`ExecApprovalRequestEvent`](https://github.com/openai/codex/blob/de00e932dd9801de0a4faac0519162099753f331/codex-rs/protocol/src/approvals.rs#L111-L175),
  including helpers to derive the legacy default choices when older
  senders omit the field.
  - Map `codex_protocol::protocol::ReviewDecision` to app-server
  `CommandExecutionApprovalDecision` and expose the ordered list as
  experimental `availableDecisions` in
  [`CommandExecutionRequestApprovalParams`](https://github.com/openai/codex/blob/de00e932dd9801de0a4faac0519162099753f331/codex-rs/app-server-protocol/src/protocol/v2.rs#L3798-L3807).
  - Thread optional `available_decisions` through the core approval path
  so Unix shell escalation can explicitly request `ApprovedForSession` for
  session-scoped approvals instead of relying on client heuristics.
  [`unix_escalation.rs`](https://github.com/openai/codex/blob/de00e932dd9801de0a4faac0519162099753f331/codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs#L194-L214)
  - Update the TUI approval overlay to build its buttons from the ordered
  decision list, while preserving the legacy fallback when
  `available_decisions` is missing.
  - Update the app-server README, test client output, and generated schema
  artifacts to document and surface the new field.
  
  ## Testing
  
  - Add `approval_overlay.rs` coverage for explicit decision lists,
  including the generic `ApprovedForSession` path and network approval
  options.
  - Update `chatwidget/tests.rs` and app-server protocol tests to populate
  the new optional field and keep older event shapes working.
  
  ## Developers Docs
  
  - If we document `item/commandExecution/requestApproval` on
  [developers.openai.com/codex](https://developers.openai.com/codex), add
  experimental `availableDecisions` as the preferred source of approval
  choices and note that older servers may omit it.

  Michael Bolin · 2026-02-26 01:10:46 +00:00
  14116ade8d
• Revert "Add skill approval event/response (#12633)" (#12811)

  This reverts commit https://github.com/openai/codex/pull/12633. We no
  longer need this PR, because we favor sending normal exec command
  approval server request with `additional_permissions` of skill
  permissions instead

  Celia Chen · 2026-02-26 01:02:42 +00:00
  4f45668106
• Enable request_user_input in Default mode (#12735)

  ## Summary
  - allow `request_user_input` in Default collaboration mode as well as
  Plan
  - update the Default-mode instructions to prefer assumptions first and
  use `request_user_input` only when a question is unavoidable
  - update request_user_input and app-server tests to match the new
  Default-mode behavior
  - refactor collaboration-mode availability plumbing into
  `CollaborationModesConfig` for future mode-related flags
  
  ## Codex author
  `codex resume 019c9124-ed28-7c13-96c6-b916b1c97d49`

  Charley Cunningham · 2026-02-25 15:20:46 -08:00
  2f4d6ded1d
• Revert "Ensure shell command skills trigger approval (#12697)" (#12721)

  This reverts commit daf0f03ac8.
  
  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Celia Chen · 2026-02-25 22:49:53 +00:00
  b6d20748e0
• feat(app-server): thread/unsubscribe API (#10954)

  Adds a new v2 app-server API for a client to be able to unsubscribe to a
  thread:
  - New RPC method: `thread/unsubscribe`
  - New server notification: `thread/closed`
  
  Today clients can start/resume/archive threads, but there wasn’t a way
  to explicitly unload a live thread from memory without archiving it.
  With `thread/unsubscribe`, a client can indicate it is no longer
  actively working with a live Thread. If this is the only client
  subscribed to that given thread, the thread will be automatically closed
  by app-server, at which point the server will send `thread/closed` and
  `thread/status/changed` with `status: notLoaded` notifications.
  
  This gives clients a way to prevent long-running app-server processes
  from accumulating too many thread (and related) objects in memory.
  
  Closed threads will also be removed from `thread/loaded/list`.

  Owen Lin · 2026-02-25 13:14:30 -08:00
  21f7032dbb
• make 5.3-codex visible in cli for api users (#12808)

  5.3-codex released in api, mark it visible for API users via bundled
  `models.json`.

  sayan-oai · 2026-02-25 13:01:40 -08:00
  d45ffd5830
• fix: harden zsh fork tests and keep subcommand approvals deterministic (#12809)

  ## Why
  The prior
  `turn_start_shell_zsh_fork_subcommand_decline_marks_parent_declined_v2`
  assertion was brittle under Bazel: command approval payloads in the test
  could include environment-dependent wrapper/command formatting
  differences, which makes exact command-string matching flaky even when
  behavior is correct.
  
  (This regression was knowingly introduced in
  https://github.com/openai/codex/pull/12800, but it was urgent to land
  that PR.)
  
  ## What changed
  - Hardened
  `turn_start_shell_zsh_fork_subcommand_decline_marks_parent_declined_v2`
  in
  [`turn_start_zsh_fork.rs`](https://github.com/openai/codex/blob/main/codex-rs/app-server/tests/suite/v2/turn_start_zsh_fork.rs):
  - Replaced strict `approval_command.starts_with("/bin/rm")` checks with
  intent-based subcommand matching.
  - Subcommand approvals are now recognized by file-target semantics
  (`first.txt` or `second.txt`) plus `rm` intent.
  - Parent approval recognition is now more tolerant of command-format
  differences while still requiring a definitive parent command context.
  - Uses a defensive loop that waits for all target subcommand decisions
  and the parent approval request.
  - Preserved the existing regression and unit test fixes from earlier
  commits in `unix_escalation.rs` and `skill_approval.rs`.
  
  ## Verification
  - Ran the zsh fork subcommand decline regression under this change:
  -
  `turn_start_shell_zsh_fork_subcommand_decline_marks_parent_declined_v2`
  - Confirmed the test is now robust against approval-command-string
  variation instead of hardcoding one expected command shape.

  Michael Bolin · 2026-02-25 12:23:30 -08:00
  be5bca6f8d
• feat(app-server): add ThreadItem::DynamicToolCall (#12732)

  Previously, clients would call `thread/start` with dynamic_tools set,
  and when a model invokes a dynamic tool, it would just make the
  server->client `item/tool/call` request and wait for the client's
  response to complete the tool call. This works, but it doesn't have an
  `item/started` or `item/completed` event.
  
  Now we are doing this:
  - [new] emit `item/started` with `DynamicToolCall` populated with the
  call arguments
  - send an `item/tool/call` server request
  - [new] once the client responds, emit `item/completed` with
  `DynamicToolCall` populated with the response.
  
  Also, with `persistExtendedHistory: true`, dynamic tool calls are now
  reconstructable in `thread/read` and `thread/resume` as
  `ThreadItem::DynamicToolCall`.

  Owen Lin · 2026-02-25 12:00:10 -08:00
  a0fd94bde6
• Add app-server v2 thread realtime API (#12715)

  Add experimental `thread/realtime/*` v2 requests and notifications, then
  route app-server realtime events through that thread-scoped surface with
  integration coverage.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-02-25 09:59:10 -08:00
  947092283a
• feat(network-proxy): add embedded OTEL policy audit logging (#12046)

  **PR Summary**
  
  This PR adds embedded-only OTEL policy audit logging for
  `codex-network-proxy` and threads audit metadata from `codex-core` into
  managed proxy startup.
  
  ### What changed
  - Added structured audit event emission in `network_policy.rs` with
  target `codex_otel.network_proxy`.
  - Emitted:
  - `codex.network_proxy.domain_policy_decision` once per domain-policy
  evaluation.
    - `codex.network_proxy.block_decision` for non-domain denies.
  - Added required policy/network fields, RFC3339 UTC millisecond
  `event.timestamp`, and fallback defaults (`http.request.method="none"`,
  `client.address="unknown"`).
  - Added non-domain deny audit emission in HTTP/SOCKS handlers for
  mode-guard and proxy-state denies, including unix-socket deny paths.
  - Added `REASON_UNIX_SOCKET_UNSUPPORTED` and used it for unsupported
  unix-socket auditing.
  - Added `NetworkProxyAuditMetadata` to runtime/state, re-exported from
  `lib.rs` and `state.rs`.
  - Added `start_proxy_with_audit_metadata(...)` in core config, with
  `start_proxy()` delegating to default metadata.
  - Wired metadata construction in `codex.rs` from session/auth context,
  including originator sanitization for OTEL-safe tagging.
  - Updated `network-proxy/README.md` with embedded-mode audit schema and
  behavior notes.
  - Refactored HTTP block-audit emission to a small local helper to reduce
  duplication.
  - Preserved existing unix-socket proxy-disabled host/path behavior for
  responses and blocked history while using an audit-only endpoint
  override (`server.address="unix-socket"`, `server.port=0`).
  
  ### Explicit exclusions
  - No standalone proxy OTEL startup work.
  - No `main.rs` binary wiring.
  - No `standalone_otel.rs`.
  - No standalone docs/tests.
  
  ### Tests
  - Extended `network_policy.rs` tests for event mapping, metadata
  propagation, fallbacks, timestamp format, and target prefix.
  - Extended HTTP tests to assert unix-socket deny block audit events.
  - Extended SOCKS tests to cover deny emission from handler deny
  branches.
  - Added/updated core tests to verify audit metadata threading into
  managed proxy state.
  
  ### Validation run
  - `just fmt`
  - `cargo test -p codex-network-proxy` ✅
  - `cargo test -p codex-core` ran with one unrelated flaky timeout
  (`shell_snapshot::tests::snapshot_shell_does_not_inherit_stdin`), and
  the test passed when rerun directly ✅
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  mcgrew-oai · 2026-02-25 11:46:37 -05:00
  9a393c9b6f
• Support external agent config detect and import (#12660)

  Migration Behavior
  
  * Config
    *  Migrates settings.json into config.toml
  * Only adds fields when config.toml is missing, or when those fields are
  missing from the existing file
    *  Supported mappings:
      env -> shell_environment_policy
       sandbox.enabled = true -> sandbox_mode = "workspace-write"
  
  * Skills
    *  Copies home and repo .claude/skills into .agents/skills
    *  Existing skill directories are not overwritten
    *  SKILL.md content is rewritten from Claude-related terms to Codex
  
  * AgentsMd
    *  Repo only
    *  Migrates CLAUDE.md into AGENTS.md
  * Detect/import only proceed when AGENTS.md is missing or present but
  empty
    *  Content is rewritten from Claude-related terms to Codex

  alexsong-oai · 2026-02-25 02:11:51 -08:00
  6d6570d89d
• feat: add search term to thread list (#12578)

  Add `searchTerm` to `thread/list` that will search for a match in the
  titles (the condition being `searchTerm` $$\in$$ `title`)

  jif-oai · 2026-02-25 09:59:41 +00:00
  f46b767b7e
• 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(ui): add network approval persistence plumbing (#12358)

  ## Summary
  - add TUI approval options for persistent network host rules
  - add app-server v2 approval payload plumbing for network approval
  context + proposed network policy amendments
  - add app-server handling to translate `applyNetworkPolicyAmendment`
  decisions back into core review decisions
  - update docs/test client output and generated app-server schemas/types

  viyatb-oai · 2026-02-25 07:06:19 +00:00
  c086b36b58
• feat: add experimental additionalPermissions to v2 command execution approval requests (#12737)

  This adds additionalPermissions to the app-server v2
  item/commandExecution/requestApproval payload as an experimental field.
  
  The field is now exposed on CommandExecutionRequestApprovalParams and is
  populated from the existing core approval event when a command requests
  additional sandbox permissions.
  
  This PR also contains changes to make server requests to support
  experiment API.
  
  A real app server test client test:
  
  sample payload with experimental flag off:
  ```
   {
  <   "id": 0,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "command": "/bin/zsh -lc 'mkdir -p ~/some/test && touch ~/some/test/file'",
  <     "commandActions": [
  <       {
  <         "command": "mkdir -p '~/some/test'",
  <         "type": "unknown"
  <       },
  <       {
  <         "command": "touch '~/some/test/file'",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Users/celia/code/codex/codex-rs",
  <     "itemId": "call_QLp0LWkQ1XkU6VW9T2vUZFWB",
  <     "proposedExecpolicyAmendment": [
  <       "mkdir",
  <       "-p",
  <       "~/some/test"
  <     ],
  <     "reason": "Do you want to allow creating ~/some/test/file outside the workspace?",
  <     "threadId": "019c9309-e209-7d82-a01b-dcf9556a354d",
  <     "turnId": "019c9309-e27a-7f33-834f-6011e795c2d6"
  <   }
  < }
  ```
  with experimental flag on: 
  ```
  < {
  <   "id": 0,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "additionalPermissions": {
  <       "fileSystem": null,
  <       "macos": null,
  <       "network": true
  <     },
  <     "command": "/bin/zsh -lc 'install -D /dev/null ~/some/test/file'",
  <     "commandActions": [
  <       {
  <         "command": "install -D /dev/null '~/some/test/file'",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Users/celia/code/codex/codex-rs",
  <     "itemId": "call_K3U4b3dRbj3eMCqslmncbGsq",
  <     "proposedExecpolicyAmendment": [
  <       "install",
  <       "-D"
  <     ],
  <     "reason": "Do you want to allow creating the file at ~/some/test/file outside the workspace sandbox?",
  <     "threadId": "019c9303-3a8e-76e1-81bf-d67ac446d892",
  <     "turnId": "019c9303-3af1-7143-88a1-73132f771234"
  <   }
  < }
  ```

  Celia Chen · 2026-02-25 05:16:35 +00:00
  1151972fb2
• 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
• Agent jobs (spawn_agents_on_csv) + progress UI (#10935)

  ## Summary
  - Add agent job support: spawn a batch of sub-agents from CSV, auto-run,
  auto-export, and store results in SQLite.
  - Simplify workflow: remove run/resume/get-status/export tools; spawn is
  deterministic and completes in one call.
  - Improve exec UX: stable, single-line progress bar with ETA; suppress
  sub-agent chatter in exec.
  
  ## Why
  Enables map-reduce style workflows over arbitrarily large repos using
  the existing Codex orchestrator. This addresses review feedback about
  overly complex job controls and non-deterministic monitoring.
  
  ## Demo (progress bar)
  ```
  ./codex-rs/target/debug/codex exec \
    --enable collab \
    --enable sqlite \
    --full-auto \
    --progress-cursor \
    -c agents.max_threads=16 \
    -C /Users/daveaitel/code/codex \
    - <<'PROMPT'
  Create /tmp/agent_job_progress_demo.csv with columns: path,area and 30 rows:
  path = item-01..item-30, area = test.
  
  Then call spawn_agents_on_csv with:
  - csv_path: /tmp/agent_job_progress_demo.csv
  - instruction: "Run `python - <<'PY'` to sleep a random 0.3–1.2s, then output JSON with keys: path, score (int). Set score = 1."
  - output_csv_path: /tmp/agent_job_progress_demo_out.csv
  PROMPT
  ```
  
  ## Review feedback addressed
  - Auto-start jobs on spawn; removed run/resume/status/export tools.
  - Auto-export on success.
  - More descriptive tool spec + clearer prompts.
  - Avoid deadlocks on spawn failure; pending/running handled safely.
  - Progress bar no longer scrolls; stable single-line redraw.
  
  ## Tests
  - `cd codex-rs && cargo test -p codex-exec`
  - `cd codex-rs && cargo build -p codex-cli`

  daveaitel-openai · 2026-02-24 21:00:19 +00:00
  dcab40123f
• 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
• feat: run zsh fork shell tool via shell-escalation (#12649)

  ## Why
  
  This PR switches the `shell_command` zsh-fork path over to
  `codex-shell-escalation` so the new shell tool can use the shared
  exec-wrapper/escalation protocol instead of the `zsh_exec_bridge`
  implementation that was introduced in
  https://github.com/openai/codex/pull/12052. `zsh_exec_bridge` relied on
  UNIX domain sockets, which is not as tamper-proof as the FD-based
  approach in `codex-shell-escalation`.
  
  ## What Changed
  
  - Added a Unix zsh-fork runtime adapter in `core`
  (`core/src/tools/runtimes/shell/unix_escalation.rs`) that:
  - runs zsh-fork commands through
  `codex_shell_escalation::run_escalate_server`
    - bridges exec-policy / approval decisions into `ShellActionProvider`
  - executes escalated commands via a `ShellCommandExecutor` that calls
  `process_exec_tool_call`
  - Updated `ShellRuntime` / `ShellCommandHandler` / tool spec wiring to
  select a `shell_command` backend (`classic` vs `zsh-fork`) while leaving
  the generic `shell` tool path unchanged.
  - Removed the `zsh_exec_bridge`-based session service and deleted
  `core/src/zsh_exec_bridge/mod.rs`.
  - Moved exec-wrapper entrypoint dispatch to `arg0` by handling the
  `codex-execve-wrapper` arg0 alias there, and removed the old
  `codex_core::maybe_run_zsh_exec_wrapper_mode()` hooks from `cli` and
  `app-server` mains.
  - Added the needed `codex-shell-escalation` dependencies for `core` and
  `arg0`.
  
  ## Tests
  
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-app-server turn_start_shell_zsh_fork --
  --nocapture`
  - verifies zsh-fork command execution and approval flows through the new
  backend
  - includes subcommand approve/decline coverage using the shared zsh
  DotSlash fixture in `app-server/tests/suite/zsh`
  - To test manually, I added the following to `~/.codex/config.toml`:
  
  ```toml
  zsh_path = "/Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh"
  
  [features]
  shell_zsh_fork = true
  ```
  
  Then I ran `just c` to run the dev build of Codex with these changes and
  sent it the message:
  
  ```
  run `echo $0`
  ```
  
  And it replied with:
  
  ```
    echo $0 printed:
  
    /Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh
  
    In this tool context, $0 reflects the script path used to invoke the shell, not just zsh.
  ```
  
  so the tool appears to be wired up correctly.
  
  ## Notes
  
  - The zsh subcommand-decline integration test now uses `rm` under a
  `WorkspaceWrite` sandbox. The previous `/usr/bin/true` scenario is
  auto-allowed by the new `shell-escalation` policy path, which no longer
  produces subcommand approval prompts.

  Michael Bolin · 2026-02-24 10:31:08 -08:00
  3ca0e7673b
• feat(core) Introduce Feature::RequestPermissions (#11871)

  ## Summary
  Introduces the initial implementation of Feature::RequestPermissions.
  RequestPermissions allows the model to request that a command be run
  inside the sandbox, with additional permissions, like writing to a
  specific folder. Eventually this will include other rules as well, and
  the ability to persist these permissions, but this PR is already quite
  large - let's get the core flow working and go from there!
  
  <img width="1279" height="541" alt="Screenshot 2026-02-15 at 2 26 22 PM"
  src="https://github.com/user-attachments/assets/0ee3ec0f-02ec-4509-91a2-809ac80be368"
  />
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally
  - [x] Feature

  Dylan Hurd · 2026-02-24 09:48:57 -08:00
  f6053fdfb3
• chore: rm hardcoded PRESETS list (#12650)

  rm `PRESETS` list harcoded in `model_presets` as we now have bundled
  `models.json` with equivalent info.
  
  update logic to rely on bundled models instead, update tests.

  sayan-oai · 2026-02-23 22:35:51 -08:00
  7e46e5b9c2
• Add skill approval event/response (#12633)

  Set the stage for skill-level permission approval in addition to
  command-level.
  
  Behind a feature flag.

  pakrym-oai · 2026-02-23 22:28:58 -08:00
  58763afa0f
• refactor: delete exec-server and move execve wrapper into shell-escalation (#12632)

  ## Why
  
  We already plan to remove the shell-tool MCP path, and doing that
  cleanup first makes the follow-on `shell-escalation` work much simpler.
  
  This change removes the last remaining reason to keep
  `codex-rs/exec-server` around by moving the `codex-execve-wrapper`
  binary and shared shell test fixtures to the crates/tests that now own
  that functionality.
  
  ## What Changed
  
  ### Delete `codex-rs/exec-server`
  
  - Remove the `exec-server` crate, including the MCP server binary,
  MCP-specific modules, and its test support/test suite
  - Remove `exec-server` from the `codex-rs` workspace and update
  `Cargo.lock`
  
  ### Move `codex-execve-wrapper` into `codex-rs/shell-escalation`
  
  - Move the wrapper implementation into `shell-escalation`
  (`src/unix/execve_wrapper.rs`)
  - Add the `codex-execve-wrapper` binary entrypoint under
  `shell-escalation/src/bin/`
  - Update `shell-escalation` exports/module layout so the wrapper
  entrypoint is hosted there
  - Move the wrapper README content from `exec-server` to
  `shell-escalation/README.md`
  
  ### Move shared shell test fixtures to `app-server`
  
  - Move the DotSlash `bash`/`zsh` test fixtures from
  `exec-server/tests/suite/` to `app-server/tests/suite/`
  - Update `app-server` zsh-fork tests to reference the new fixture paths
  
  ### Keep `shell-tool-mcp` as a shell-assets package
  
  - Update `.github/workflows/shell-tool-mcp.yml` packaging so the npm
  artifact contains only patched Bash/Zsh payloads (no Rust binaries)
  - Update `shell-tool-mcp/package.json`, `shell-tool-mcp/src/index.ts`,
  and docs to reflect the shell-assets-only package shape
  - `shell-tool-mcp-ci.yml` does not need changes because it is already
  JS-only
  
  ## Verification
  
  - `cargo shear`
  - `cargo clippy -p codex-shell-escalation --tests`
  - `just clippy`

  Michael Bolin · 2026-02-23 20:10:22 -08:00
  38f84b6b29
• app-server: fix connecting via websockets with Sec-WebSocket-Extensions: permessage-deflate (#12629)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Javi · 2026-02-24 02:41:03 +00:00
  5a3bdcb27b
• app-server: box request dispatch future to reduce stack pressure (#12421)
  Charley Cunningham · 2026-02-23 10:05:41 -08:00
  3cea3e665e
• test: vendor zsh fork via DotSlash and stabilize zsh-fork tests (#12518)

  ## Why
  
  The zsh integration tests were still brittle in two ways:
  
  - they relied on `CODEX_TEST_ZSH_PATH` / environment-specific setup, so
  they often did not exercise the patched zsh fork that `shell-tool-mcp`
  ships
  - once the tests consistently used the vendored zsh fork, they exposed
  real Linux-specific zsh-fork issues in CI
  
  In particular, the Linux failures were not just test noise:
  
  - the zsh-fork launch path was dropping `ExecRequest.arg0`, so Linux
  `codex-linux-sandbox` arg0 dispatch did not run and zsh wrapper-mode
  could receive malformed arguments
  - the
  `turn_start_shell_zsh_fork_subcommand_decline_marks_parent_declined_v2`
  test uses the zsh exec bridge (which talks to the parent over a Unix
  socket), but Linux restricted sandbox seccomp denies `connect(2)`,
  causing timeouts on `ubuntu-24.04` x86/arm
  
  This PR makes the zsh tests consistently run against the intended
  vendored zsh fork and fixes/hardens the zsh-fork path so the Linux CI
  signal is meaningful.
  
  ## What Changed
  
  - Added a single shared test-only DotSlash file for the patched zsh fork
  at `codex-rs/exec-server/tests/suite/zsh` (analogous to the existing
  `bash` test resource).
  - Updated both app-server and exec-server zsh tests to use that shared
  DotSlash zsh (no duplicate zsh DotSlash file, no `CODEX_TEST_ZSH_PATH`
  dependency).
  - Updated the app-server zsh-fork test helper to resolve the shared
  DotSlash zsh and avoid silently falling back to host zsh.
  - Kept the app-server zsh-fork tests configured via `config.toml`, using
  a test wrapper path where needed to force `zsh -df` (and rewrite `-lc`
  to `-c`) for the subcommand-decline test.
  - Hardened the app-server subcommand-decline zsh-fork test for CI
  variability:
    - tolerate an extra `/responses` POST with a no-op mock response
  - tolerate non-target approval ordering while remaining strict on the
  two `/usr/bin/true` approvals and decline behavior
  - use `DangerFullAccess` on Linux for this one test because it validates
  zsh approval flow, not Linux sandbox socket restrictions
  - Fixed zsh-fork process launching on Linux by preserving `req.arg0` in
  `ZshExecBridge::execute_shell_request(...)` so `codex-linux-sandbox`
  arg0 dispatch continues to work.
  - Moved `maybe_run_zsh_exec_wrapper_mode()` under
  `arg0_dispatch_or_else(...)` in `app-server` and `cli` so wrapper-mode
  handling coexists correctly with arg0-dispatched helper modes.
  - Consolidated duplicated `dotslash -- fetch` resolution logic into
  shared test support (`core/tests/common/lib.rs`).
  - Updated `codex-rs/exec-server/tests/suite/accept_elicitation.rs` to
  use DotSlash zsh and hardened the zsh elicitation test for Bazel/zsh
  differences by:
    - resolving an absolute `git` path
    - running `git init --quiet .`
  - asserting success / `.git` creation instead of relying on banner text
  
  ## Verification
  
  - `cargo test -p codex-app-server turn_start_zsh_fork -- --nocapture`
  - `cargo test -p codex-exec-server accept_elicitation -- --nocapture`
  - `bazel test //codex-rs/exec-server:exec-server-all-test
  --test_output=streamed --test_arg=--nocapture
  --test_arg=accept_elicitation_for_prompt_rule_with_zsh`
  - CI (`rust-ci`) on the final cleaned commit: `Tests — ubuntu-24.04 -
  x86_64-unknown-linux-gnu` and `Tests — ubuntu-24.04-arm -
  aarch64-unknown-linux-gnu` passed in [run
  22291424358](https://github.com/openai/codex/actions/runs/22291424358)

  Michael Bolin · 2026-02-22 19:39:56 -08:00
  e8949f4507
• 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
• test(app-server): wait for turn/completed in turn_start tests (#12376)

  ## Summary
  - switch a few app-server `turn_start` tests from
  `codex/event/task_complete` waits to `turn/completed` waits
  - avoid matching unrelated/background `task_complete` events
  - keep this flaky test fix separate from the /title feature PR
  
  ## Why
  On Windows ARM CI, these tests can return early after observing a
  generic `codex/event/task_complete` notification from another task. That
  can leave the mock Responses server with fewer calls than expected and
  fail the test with a wiremock verification mismatch.
  
  Using `turn/completed` matches the app-server turn lifecycle
  notification the tests actually care about.
  
  ## Validation
  - `cargo test -p codex-app-server
  turn_start_updates_sandbox_and_cwd_between_turns_v2 -- --nocapture`
  - `cargo test -p codex-app-server turn_start_exec_approval_ --
  --nocapture`
  - `just fmt`

  Yaroslav Volovich · 2026-02-20 21:15:21 -08:00
  dca9c40dd5