151 Commits

• Show spawned agent model and effort in TUI (#14273)

  - include the requested sub-agent model and reasoning effort in the
  spawn begin event\n- render that metadata next to the spawned agent name
  and role in the TUI transcript
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-11 12:33:09 -07:00
  285b3a5143
• app-server service tier plumbing (plus some cleanup) (#13334)

  followup to https://github.com/openai/codex/pull/13212 to expose fast
  tier controls to app server
  (majority of this PR is generated schema jsons - actual code is +69 /
  -35 and +24 tests )
  
  - add service tier fields to the app-server protocol surfaces used by
  thread lifecycle, turn start, config, and session configured events
  - thread service tier through the app-server message processor and core
  thread config snapshots
  - allow runtime config overrides to carry service tier for app-server
  callers
  
  cleanup:
  - Removing useless "legacy" code supporting "standard" - we moved to
  None | "fast", so "standard" is not needed.

  pash-openai · 2026-03-03 02:35:09 -08:00
  07e532dcb9
• 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
• fix: flaky test due to second-resolution for thread ordering (#12692)
  jif-oai · 2026-02-25 09:59:25 +00:00
  a046849438
• fix(exec) Patch resume test race condition (#12648)

  ## Summary
  The test exec_resume_last_respects_cwd_filter_and_all_flag makes one
  session “newest” by resuming it, but rollout updated_at is stored/sorted
  at second precision. On fast CI (especially Windows), the touch could
  land in the same second as initial session creation, making ordering
  nondeterministic.
  
  This change adds a short sleep before the recency-touch step so the
  resumed session is guaranteed to have a later updated_at, preserving the
  intended assertion without changing product behavior.

  Dylan Hurd · 2026-02-23 21:54:25 -08:00
  fbeda61cc3
• feat: land sqlite (#12141)
  jif-oai · 2026-02-23 16:12:23 +00:00
  eace7c6610
• fix: codex-arg0 no longer depends on codex-core (#12434)

  ## Why
  
  `codex-rs/arg0` only needed two things from `codex-core`:
  
  - the `find_codex_home()` wrapper
  - the special argv flag used for the internal `apply_patch`
  self-invocation path
  
  That made `codex-arg0` depend on `codex-core` for a very small surface
  area. This change removes that dependency edge and moves the shared
  `apply_patch` invocation flag to a more natural boundary
  (`codex-apply-patch`) while keeping the contract explicitly documented.
  
  ## What Changed
  
  - Moved the internal `apply_patch` argv[1] flag constant out of
  `codex-core` and into `codex-apply-patch`.
  - Renamed the constant to `CODEX_CORE_APPLY_PATCH_ARG1` and documented
  that it is part of the Codex core process-invocation contract (even
  though it now lives in `codex-apply-patch`).
  - Updated `arg0`, the core apply-patch runtime, and the `codex-exec`
  apply-patch test to import the constant from `codex-apply-patch`.
  - Updated `codex-rs/arg0` to call
  `codex_utils_home_dir::find_codex_home()` directly instead of
  `codex_core::config::find_codex_home()`.
  - Removed the `codex-core` dependency from `codex-rs/arg0` and added the
  needed direct dependency on `codex-utils-home-dir`.
  - Added `codex-apply-patch` as a dev-dependency for `codex-rs/exec`
  tests (the apply-patch test now imports the moved constant directly).
  
  ## Verification
  
  - `cargo test -p codex-apply-patch`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core --lib apply_patch`
  - `cargo test -p codex-exec
  test_standalone_exec_cli_can_use_apply_patch`
  - `cargo shear`

  Michael Bolin · 2026-02-21 00:20:42 -08:00
  2fe4be1aa9
• 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
• feat: cleaner TUI for sub-agents (#12327)

  <img width="760" height="496" alt="Screenshot 2026-02-20 at 14 31 25"
  src="https://github.com/user-attachments/assets/1983b825-bb47-417e-9925-6f727af56765"
  />

  jif-oai · 2026-02-20 15:26:33 +00:00
  4d60c803ba
• Restore phase when loading from history (#12244)
  Jack Mousseau · 2026-02-19 09:56:56 -08:00
  3a951f8096
• 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
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• 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
• 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
• feat(sandbox): enforce proxy-aware network routing in sandbox (#11113)

  ## Summary
  - expand proxy env injection to cover common tool env vars
  (`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`/`NO_PROXY` families +
  tool-specific variants)
  - harden macOS Seatbelt network policy generation to route through
  inferred loopback proxy endpoints and fail closed when proxy env is
  malformed
  - thread proxy-aware Linux sandbox flags and add minimal bwrap netns
  isolation hook for restricted non-proxy runs
  - add/refresh tests for proxy env wiring, Seatbelt policy generation,
  and Linux sandbox argument wiring

  viyatb-oai · 2026-02-10 07:44:21 +00:00
  3391e5ea86
• Handle required MCP startup failures across components (#10902)

  Summary
  - add a `required` flag for MCP servers everywhere config/CLI data is
  touched so mandatory helpers can be round-tripped
  - have `codex exec` and `codex app-server` thread start/resume fail fast
  when required MCPs fail to initialize

  jif-oai · 2026-02-06 17:14:37 +01:00
  aab61934af
• feat: wire ephemeral in codex exec (#10758)
  jif-oai · 2026-02-05 15:49:57 +00:00
  d337b51741
• fix: flaky landlock (#10689)

  https://openai.slack.com/archives/C095U48JNL9/p1770243347893959

  jif-oai · 2026-02-05 10:30:18 +00:00
  c67120f4a0
• feat(linux-sandbox): add bwrap support (#9938)

  ## Summary
  This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
  curent Linux sandbox path relies on in-process restrictions (including
  Landlock). Bubblewrap gives us a more uniform filesystem isolation
  model, especially explicit writable roots with the option to make some
  directories read-only and granular network controls.
  
  This is behind a feature flag so we can validate behavior safely before
  making it the default.
  
  - Added temporary rollout flag:
    - `features.use_linux_sandbox_bwrap`
  - Preserved existing default path when the flag is off.
  - In Bubblewrap mode:
  - Added internal retry without /proc when /proc mount is not permitted
  by the host/container.

  viyatb-oai · 2026-02-04 11:13:17 -08:00
  ae4de43ccc
• Cleanup collaboration mode variants (#10404)

  ## Summary
  
  This PR simplifies collaboration modes to the visible set `default |
  plan`, while preserving backward compatibility for older partners that
  may still send legacy mode
  names.
  
  Specifically:
  - Renames the old Code behavior to **Default**.
  - Keeps **Plan** as-is.
  - Removes **Custom** mode behavior (fallbacks now resolve to Default).
  - Keeps `PairProgramming` and `Execute` internally for compatibility
  plumbing, while removing them from schema/API and UI visibility.
  - Adds legacy input aliasing so older clients can still send old mode
  names.
  
  ## What Changed
  
  1. Mode enum and compatibility
  - `ModeKind` now uses `Plan` + `Default` as active/public modes.
  - `ModeKind::Default` deserialization accepts legacy values:
    - `code`
    - `pair_programming`
    - `execute`
    - `custom`
  - `PairProgramming` and `Execute` variants remain in code but are hidden
  from protocol/schema generation.
  - `Custom` variant is removed; previous custom fallbacks now map to
  `Default`.
  
  2. Collaboration presets and templates
  - Built-in presets now return only:
    - `Plan`
    - `Default`
  - Template rename:
    - `core/templates/collaboration_mode/code.md` -> `default.md`
  - `execute.md` and `pair_programming.md` remain on disk but are not
  surfaced in visible preset lists.
  
  3. TUI updates
  - Updated user-facing naming and prompts from “Code” to “Default”.
  - Updated mode-cycle and indicator behavior to reflect only visible
  `Plan` and `Default`.
  - Updated corresponding tests and snapshots.
  
  4. request_user_input behavior
  - `request_user_input` remains allowed only in `Plan` mode.
  - Rejection messaging now consistently treats non-plan modes as
  `Default`.
  
  5. Schemas
  - Regenerated config and app-server schemas.
  - Public schema types now advertise mode values as:
    - `plan`
    - `default`
  
  ## Backward Compatibility Notes
  
  - Incoming legacy mode names (`code`, `pair_programming`, `execute`,
  `custom`) are accepted and coerced to `default`.
  - Outgoing/public schema surfaces intentionally expose only `plan |
  default`.
  - This allows tolerant ingestion of older partner payloads while
  standardizing new integrations on the reduced mode set.
  
  ## Codex author
  `codex fork 019c1fae-693b-7840-b16e-9ad38ea0bd00`

  Charley Cunningham · 2026-02-03 09:23:53 -08:00
  d509df676b
• feat: replace custom mcp-types crate with equivalents from rmcp (#10349)

  We started working with MCP in Codex before
  https://crates.io/crates/rmcp was mature, so we had our own crate for
  MCP types that was generated from the MCP schema:
  
  
  https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
  
  Now that `rmcp` is more mature, it makes more sense to use their MCP
  types in Rust, as they handle details (like the `_meta` field) that our
  custom version ignored. Though one advantage that our custom types had
  is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
  whereas the types in `rmcp` do not. As such, part of the work of this PR
  is leveraging the adapters between `rmcp` types and the serializable
  types that are API for us (app server and MCP) introduced in #10356.
  
  Note this PR results in a number of changes to
  `codex-rs/app-server-protocol/schema`, which merit special attention
  during review. We must ensure that these changes are still
  backwards-compatible, which is possible because we have:
  
  ```diff
  - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
  + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
  ```
  
  so `ContentBlock` has been replaced with the more general `JsonValue`.
  Note that `ContentBlock` was defined as:
  
  ```typescript
  export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
  ```
  
  so the deletion of those individual variants should not be a cause of
  great concern.
  
  Similarly, we have the following change in
  `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
  
  ```
  - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
  + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
  ```
  
  so:
  
  - `annotations?: ToolAnnotations` ➡️ `JsonValue`
  - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
  - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
  
  and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
  * #10357
  * __->__ #10349
  * #10356

  Michael Bolin · 2026-02-02 17:41:55 -08:00
  66447d5d2c
• add missing fields to WebSearchAction and update app-server types (#10276)

  - add `WebSearchAction` to app-server v2 types
  - add `queries` to `WebSearchAction::Search` type
  
  Updated tests.

  sayan-oai · 2026-01-30 16:37:56 -08:00
  eb86663dcb
• Plan mode: stream proposed plans, emit plan items, and render in TUI (#9786)

  ## Summary
  - Stream proposed plans in Plan Mode using `<proposed_plan>` tags parsed
  in core, emitting plan deltas plus a plan `ThreadItem`, while stripping
  tags from normal assistant output.
  - Persist plan items and rebuild them on resume so proposed plans show
  in thread history.
  - Wire plan items/deltas through app-server protocol v2 and render a
  dedicated proposed-plan view in the TUI, including the “Implement this
  plan?” prompt only when a plan item is present.
  
  ## Changes
  
  ### Core (`codex-rs/core`)
  - Added a generic, line-based tag parser that buffers each line until it
  can disprove a tag prefix; implements auto-close on `finish()` for
  unterminated tags. `codex-rs/core/src/tagged_block_parser.rs`
  - Refactored proposed plan parsing to wrap the generic parser.
  `codex-rs/core/src/proposed_plan_parser.rs`
  - In plan mode, stream assistant deltas as:
    - **Normal text** → `AgentMessageContentDelta`
    - **Plan text** → `PlanDelta` + `TurnItem::Plan` start/completion  
    (`codex-rs/core/src/codex.rs`)
  - Final plan item content is derived from the completed assistant
  message (authoritative), not necessarily the concatenated deltas.
  - Strips `<proposed_plan>` blocks from assistant text in plan mode so
  tags don’t appear in normal messages.
  (`codex-rs/core/src/stream_events_utils.rs`)
  - Persist `ItemCompleted` events only for plan items for rollout replay.
  (`codex-rs/core/src/rollout/policy.rs`)
  - Guard `update_plan` tool in Plan Mode with a clear error message.
  (`codex-rs/core/src/tools/handlers/plan.rs`)
  - Updated Plan Mode prompt to:  
    - keep `<proposed_plan>` out of non-final reasoning/preambles  
    - require exact tag formatting  
    - allow only one `<proposed_plan>` block per turn  
    (`codex-rs/core/templates/collaboration_mode/plan.md`)
  
  ### Protocol / App-server protocol
  - Added `TurnItem::Plan` and `PlanDeltaEvent` to core protocol items.
  (`codex-rs/protocol/src/items.rs`, `codex-rs/protocol/src/protocol.rs`)
  - Added v2 `ThreadItem::Plan` and `PlanDeltaNotification` with
  EXPERIMENTAL markers and note that deltas may not match the final plan
  item. (`codex-rs/app-server-protocol/src/protocol/v2.rs`)
  - Added plan delta route in app-server protocol common mapping.
  (`codex-rs/app-server-protocol/src/protocol/common.rs`)
  - Rebuild plan items from persisted `ItemCompleted` events on resume.
  (`codex-rs/app-server-protocol/src/protocol/thread_history.rs`)
  
  ### App-server
  - Forward plan deltas to v2 clients and map core plan items to v2 plan
  items. (`codex-rs/app-server/src/bespoke_event_handling.rs`,
  `codex-rs/app-server/src/codex_message_processor.rs`)
  - Added v2 plan item tests.
  (`codex-rs/app-server/tests/suite/v2/plan_item.rs`)
  
  ### TUI
  - Added a dedicated proposed plan history cell with special background
  and padding, and moved “• Proposed Plan” outside the highlighted block.
  (`codex-rs/tui/src/history_cell.rs`, `codex-rs/tui/src/style.rs`)
  - Only show “Implement this plan?” when a plan item exists.
  (`codex-rs/tui/src/chatwidget.rs`,
  `codex-rs/tui/src/chatwidget/tests.rs`)
  
  <img width="831" height="847" alt="Screenshot 2026-01-29 at 7 06 24 PM"
  src="https://github.com/user-attachments/assets/69794c8c-f96b-4d36-92ef-c1f5c3a8f286"
  />
  
  ### Docs / Misc
  - Updated protocol docs to mention plan deltas.
  (`codex-rs/docs/protocol_v1.md`)
  - Minor plumbing updates in exec/debug clients to tolerate plan deltas.
  (`codex-rs/debug-client/src/reader.rs`, `codex-rs/exec/...`)
  
  ## Tests
  - Added core integration tests:
    - Plan mode strips plan from agent messages.
    - Missing `</proposed_plan>` closes at end-of-message.  
    (`codex-rs/core/tests/suite/items.rs`)
  - Added unit tests for generic tag parser (prefix buffering, non-tag
  lines, auto-close). (`codex-rs/core/src/tagged_block_parser.rs`)
  - Existing app-server plan item tests in v2.
  (`codex-rs/app-server/tests/suite/v2/plan_item.rs`)
  
  ## Notes / Behavior
  - Plan output no longer appears in standard assistant text in Plan Mode;
  it streams via `PlanDelta` and completes as a `TurnItem::Plan`.
  - The final plan item content is authoritative and may diverge from
  streamed deltas (documented as experimental).
  - Reasoning summaries are not filtered; prompt instructs the model not
  to include `<proposed_plan>` outside the final plan message.
  
  ## Codex Author
  `codex fork 019bec2d-b09d-7450-b292-d7bcdddcdbfb`

  Charley Cunningham · 2026-01-30 18:59:30 +00:00
  ec4a2d07e4
• Conversation naming (#8991)

  Session renaming:
  - `/rename my_session`
  - `/rename` without arg and passing an argument in `customViewPrompt`
  - AppExitInfo shows resume hint using the session name if set instead of
  uuid, defaults to uuid if not set
  - Names are stored in `CODEX_HOME/sessions.jsonl`
  
  Session resuming:
  - codex resume <name> lookup for `CODEX_HOME/sessions.jsonl` first entry
  matching the name and resumes the session
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  pap-openai · 2026-01-30 10:40:09 +00:00
  1ef5455eb6
• [bazel] Improve runfiles handling (#10098)

  we can't use runfiles directory on Windows due to path lengths, so swap
  to manifest strategy. Parsing the manifest is a bit complex and the
  format is changing in Bazel upstream, so pull in the official Rust
  library (via a small hack to make it importable...) and cleanup all the
  associated logic to work cleanly in both bazel and cargo without extra
  confusion

  zbarsky-openai · 2026-01-29 00:15:44 +00:00
  8497163363
• fix: handle all web_search actions and in progress invocations (#9960)

  ### Summary
  - Parse all `web_search` tool actions (`search`, `find_in_page`,
  `open_page`).
  - Previously we only parsed + displayed `search`, which made the TUI
  appear to pause when the other actions were being used.
  - Show in progress `web_search` calls as `Searching the web`
    - Previously we only showed completed tool calls
  
  <img width="308" height="149" alt="image"
  src="https://github.com/user-attachments/assets/90a4e8ff-b06a-48ff-a282-b57b31121845"
  />
  
  ### Tests
  Added + updated tests, tested locally
  
  ### Follow ups
  Update VSCode extension to display these as well

  sayan-oai · 2026-01-27 03:33:48 +00:00
  86adf53235
• feat: codex exec mapping of collab tools (#9817)

  THIS IS NOT THE FINAL UX

  jif-oai · 2026-01-26 18:01:35 +00:00
  01d7f8095b
• Fix flakey resume test (#9789)

  Sessions' `updated_at` times are truncated to seconds, with the UUID
  session ID used to break ties. If the two test sessions are created in
  the same second, AND the session B UUID < session A UUID, the test
  fails.
  
  Fix this by mutating the session mtimes, from which we derive the
  updated_at time, to ensure session B is updated_at later than session A.

  gt-oai · 2026-01-26 14:44:37 +00:00
  65c7119fb7
• feat: ephemeral threads (#9765)

  Add ephemeral threads capabilities. Only exposed through the
  `app-server` v2
  
  The idea is to disable the rollout recorder for those threads.

  jif-oai · 2026-01-24 14:57:40 +00:00
  83775f4df1
• feat: show forked from session id in /status (#9330)

  Summary:
  - Add forked_from to SessionMeta/SessionConfiguredEvent and persist it
  for forked sessions.
  - Surface forked_from in /status for tui + tui2 and add snapshots.

  Anton Panasenko · 2026-01-16 13:41:46 -08:00
  c26fe64539
• Made codex exec resume --last consistent with codex resume --last (#9352)

  PR #9245 made `codex resume --last` honor cwd, but I forgot to make the
  same change for `codex exec resume --last`. This PR fixes the
  inconsistency.
  
  This addresses #8700

  Eric Traut · 2026-01-16 08:53:47 -08:00
  9147df0e60
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• feat: introduce find_resource! macro that works with Cargo or Bazel (#8879)

  To support Bazelification in https://github.com/openai/codex/pull/8875,
  this PR introduces a new `find_resource!` macro that we use in place of
  our existing logic in tests that looks for resources relative to the
  compile-time `CARGO_MANIFEST_DIR` env var.
  
  To make this work, we plan to add the following to all `rust_library()`
  and `rust_test()` Bazel rules in the project:
  
  ```
  rustc_env = {
      "BAZEL_PACKAGE": native.package_name(),
  },
  ```
  
  Our new `find_resource!` macro reads this value via
  `option_env!("BAZEL_PACKAGE")` so that the Bazel package _of the code
  using `find_resource!`_ is injected into the code expanded from the
  macro. (If `find_resource()` were a function, then
  `option_env!("BAZEL_PACKAGE")` would always be
  `codex-rs/utils/cargo-bin`, which is not what we want.)
  
  Note we only consider the `BAZEL_PACKAGE` value when the `RUNFILES_DIR`
  environment variable is set at runtime, indicating that the test is
  being run by Bazel. In this case, we have to concatenate the runtime
  `RUNFILES_DIR` with the compile-time `BAZEL_PACKAGE` value to build the
  path to the resource.
  
  In testing this change, I discovered one funky edge case in
  `codex-rs/exec-server/tests/common/lib.rs` where we have to _normalize_
  (but not canonicalize!) the result from `find_resource!` because the
  path contains a `common/..` component that does not exist on disk when
  the test is run under Bazel, so it must be semantically normalized using
  the [`path-absolutize`](https://crates.io/crates/path-absolutize) crate
  before it is passed to `dotslash fetch`.
  
  Because this new behavior may be non-obvious, this PR also updates
  `AGENTS.md` to make humans/Codex aware that this API is preferred.

  Michael Bolin · 2026-01-07 18:06:08 -08:00
  f6b563ec64
• chore: unify conversation with thread name (#8830)

  Done and verified by Codex + refactor feature of RustRover

  jif-oai · 2026-01-07 17:04:53 +00:00
  116059c3a0
• Allow global exec flags after resume and fix CI codex build/timeout (#8440)

  **Motivation**
  - Bring `codex exec resume` to parity with top‑level flags so global
  options (git check bypass, json, model, sandbox toggles) work after the
  subcommand, including when outside a git repo.
  
  **Description**
  - Exec CLI: mark `--skip-git-repo-check`, `--json`, `--model`,
  `--full-auto`, and `--dangerously-bypass-approvals-and-sandbox` as
  global so they’re accepted after `resume`.
  - Tests: add `exec_resume_accepts_global_flags_after_subcommand` to
  verify those flags work when passed after `resume`.
  
  **Testing**
  - `just fmt`
  - `cargo test -p codex-exec` (pass; ran with elevated perms to allow
  network/port binds)
  - Manual: exercised `codex exec resume` with global flags after the
  subcommand to confirm behavior.

  Curtis 'Fjord' Hawthorne · 2026-01-05 22:12:09 +00:00
  5f8776d34d
• [chore] add additional_details to StreamErrorEvent + wire through (#8307)

  ### What
  
  Builds on #8293.
  
  Add `additional_details`, which contains the upstream error message, to
  relevant structures used to pass along retryable `StreamError`s.
  
  Uses the new TUI status indicator's `details` field (shows under the
  status header) to display the `additional_details` error to the user on
  retryable `Reconnecting...` errors. This adds clarity for users for
  retryable errors.
  
  Will make corresponding change to VSCode extension to show
  `additional_details` as expandable from the `Reconnecting...` cell.
  
  Examples:
  <img width="1012" height="326" alt="image"
  src="https://github.com/user-attachments/assets/f35e7e6a-8f5e-4a2f-a764-358101776996"
  />
  
  <img width="1526" height="358" alt="image"
  src="https://github.com/user-attachments/assets/0029cbc0-f062-4233-8650-cc216c7808f0"
  />

  sayan-oai · 2025-12-24 10:07:38 -08:00
  bf732600ea
• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• feat: change ConfigLayerName into a disjoint union rather than a simple enum (#8095)

  This attempts to tighten up the types related to "config layers."
  Currently, `ConfigLayerEntry` is defined as follows:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/state.rs#L19-L25
  
  but the `source` field is a bit of a lie, as:
  
  - for `ConfigLayerName::Mdm`, it is
  `"com.openai.codex/config_toml_base64"`
  - for `ConfigLayerName::SessionFlags`, it is `"--config"`
  - for `ConfigLayerName::User`, it is `"config.toml"` (just the file
  name, not the path to the `config.toml` on disk that was read)
  - for `ConfigLayerName::System`, it seems like it is usually
  `/etc/codex/managed_config.toml` in practice, though on Windows, it is
  `%CODEX_HOME%/managed_config.toml`:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/layer_io.rs#L84-L101
  
  All that is to say, in three out of the four `ConfigLayerName`, `source`
  is a `PathBuf` that is not an absolute path (or even a true path).
  
  This PR tries to uplevel things by eliminating `source` from
  `ConfigLayerEntry` and turning `ConfigLayerName` into a disjoint union
  named `ConfigLayerSource` that has the appropriate metadata for each
  variant, favoring the use of `AbsolutePathBuf` where appropriate:
  
  ```rust
  pub enum ConfigLayerSource {
      /// Managed preferences layer delivered by MDM (macOS only).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      Mdm { domain: String, key: String },
      /// Managed config layer from a file (usually `managed_config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      System { file: AbsolutePathBuf },
      /// Session-layer overrides supplied via `-c`/`--config`.
      SessionFlags,
      /// User config layer from a file (usually `config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      User { file: AbsolutePathBuf },
  }
  ```

  Michael Bolin · 2025-12-17 08:13:59 -08:00
  de3fa03e1c
• Reimplement skills loading using SkillsManager + skills/list op. (#7914)

  refactor the way we load and manage skills:
  1. Move skill discovery/caching into SkillsManager and reuse it across
  sessions.
  2. Add the skills/list API (Op::ListSkills/SkillsListResponse) to fetch
  skills for one or more cwds. Also update app-server for VSCE/App;
  3. Trigger skills/list during session startup so UIs preload skills and
  handle errors immediately.

  xl-openai · 2025-12-14 09:58:17 -08:00
  5d77d4db6b
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• Inject SKILL.md when it's explicitly mentioned. (#7763)

  1. Skills load once in core at session start; the cached outcome is
  reused across core and surfaced to TUI via SessionConfigured.
  2. TUI detects explicit skill selections, and core injects the matching
  SKILL.md content into the turn when a selected skill is present.

  xl-openai · 2025-12-10 13:59:17 -08:00
  b36ecb6c32
• chore: rework unified exec events (#7775)
  jif-oai · 2025-12-10 10:30:38 +00:00
  0ad54982ae
• seatbelt: allow openpty() (#7507)

  This allows `openpty(3)` to run in the default sandbox. Also permit
  reading `kern.argmax`, which is the maximum number of arguments to
  exec().

  Jeremy Rose · 2025-12-03 09:15:38 -08:00
  9b3251f28f
• feat: update process ID for event handling (#7261)
  jif-oai · 2025-11-25 14:21:05 -08:00
  28ff364c3a
• [app-server] update doc with codex error info (#6941)

  Document new codex error info. Also fixed the name from
  `codex_error_code` to `codex_error_info`.

  Celia Chen · 2025-11-21 01:02:37 +00:00
  7e2165f394
• [app-server & core] introduce new codex error code and v2 app-server error events (#6938)

  This PR does two things:
  1. populate a new `codex_error_code` protocol in error events sent from
  core to client;
  2. old v1 core events `codex/event/stream_error` and `codex/event/error`
  will now both become `error`. We also show codex error code for
  turncompleted -> error status.
  
  new events in app server test:
  ```
  < {
  <   "method": "codex/event/stream_error",
  <   "params": {
  <     "conversationId": "019aa34c-0c14-70e0-9706-98520a760d67",
  <     "id": "0",
  <     "msg": {
  <       "codex_error_code": {
  <         "response_stream_disconnected": {
  <           "http_status_code": 401
  <         }
  <       },
  <       "message": "Reconnecting... 2/5",
  <       "type": "stream_error"
  <     }
  <   }
  < }
  
   {
  <   "method": "error",
  <   "params": {
  <     "error": {
  <       "codexErrorCode": {
  <         "responseStreamDisconnected": {
  <           "httpStatusCode": 401
  <         }
  <       },
  <       "message": "Reconnecting... 2/5"
  <     }
  <   }
  < }
  
  < {
  <   "method": "turn/completed",
  <   "params": {
  <     "turn": {
  <       "error": {
  <         "codexErrorCode": {
  <           "responseTooManyFailedAttempts": {
  <             "httpStatusCode": 401
  <           }
  <         },
  <         "message": "exceeded retry limit, last status: 401 Unauthorized, request id: 9a1b495a1a97ed3e-SJC"
  <       },
  <       "id": "0",
  <       "items": [],
  <       "status": "failed"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-20 23:06:55 +00:00
  9bce050385
• codex-exec: allow resume --last to read prompt #6717 (#6719)

  ### Description
  
  - codex exec --json resume --last "<prompt>" bailed out because clap
  treated the prompt as SESSION_ID. I removed the conflicts_with flag and
  reinterpret that positional as a prompt when
  --last is set, so the flow now keeps working in JSON mode.
  (codex-rs/exec/src/cli.rs:84-104, codex-rs/exec/src/lib.rs:75-130)
  - Added a regression test that exercises resume --last in JSON mode to
  ensure the prompt is accepted and the rollout file is updated.
  (codex-rs/exec/tests/suite/resume.rs:126-178)
  
  ### Testing
  
    - just fmt
    - cargo test -p codex-exec
    - just fix -p codex-exec
    - cargo test -p codex-exec
  
  #6717
  
  Signed-off-by: Dmitri Khokhlov <dkhokhlov@cribl.io>

  Dmitri Khokhlov · 2025-11-20 13:10:49 -08:00
  e4257f432e
• [app-server] feat: v2 apply_patch approval flow (#6760)

  This PR adds the API V2 version of the apply_patch approval flow, which
  centers around `ThreadItem::FileChange`.
  
  This PR wires the new RPC (`item/fileChange/requestApproval`, V2 only)
  and related events (`item/started`, `item/completed` for
  `ThreadItem::FileChange`, which are emitted in both V1 and V2) through
  the app-server
  protocol. The new approval RPC is only sent when the user initiates a
  turn with the new `turn/start` API so we don't break backwards
  compatibility with VSCE.
  
  Similar to https://github.com/openai/codex/pull/6758, the approach I
  took was to make as few changes to the Codex core as possible,
  leveraging existing `EventMsg` core events, and translating those in
  app-server. I did have to add a few additional fields to
  `EventMsg::PatchApplyBegin` and `EventMsg::PatchApplyEnd`, but those
  were fairly lightweight.
  
  However, the `EventMsg`s emitted by core are the following:
  ```
  1) Auto-approved (no request for approval)

  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  2) Approved by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  3) Declined by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  ```
  
  For a request triggering an approval, this would result in:
  ```
  item/fileChange/requestApproval
  item/started
  item/completed
  ```
  
  which is different from the `ThreadItem::CommandExecution` flow
  introduced in https://github.com/openai/codex/pull/6758, which does the
  below and is preferable:
  ```
  item/started
  item/commandExecution/requestApproval
  item/completed
  ```
  
  To fix this, we leverage `TurnSummaryStore` on codex_message_processor
  to store a little bit of state, allowing us to fire `item/started` and
  `item/fileChange/requestApproval` whenever we receive the underlying
  `EventMsg::ApplyPatchApprovalRequest`, and no-oping when we receive the
  `EventMsg::PatchApplyBegin` later.
  
  This is much less invasive than modifying the order of EventMsg within
  core (I tried).
  
  The resulting payloads:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "inProgress",
        "type": "fileChange"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/fileChange/requestApproval",
    "params": {
      "grantRoot": null,
      "itemId": "call_Nxnwj7B3YXigfV6Mwh03d686",
      "reason": null,
      "threadId": "019a9e11-8295-7883-a283-779e06502c6f",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "method": "item/completed",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "completed",
        "type": "fileChange"
      }
    }
  }
  ```

  Owen Lin · 2025-11-19 20:13:31 -08:00
  d6c30ed25e
• Revert "[core] add optional status_code to error events (#6865)" (#6955)

  This reverts commit c2ec477d93.
  
  # 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 · 2025-11-20 01:26:14 +00:00
  72a1453ac5
• [core] add optional status_code to error events (#6865)

  We want to better uncover error status code for clients. Add an optional
  status_code to error events (thread error, error, stream error) so app
  server could uncover the status code from the client side later.
  
  in event log:
  ```
  < {
  <   "method": "codex/event/stream_error",
  <   "params": {
  <     "conversationId": "019a9a32-f576-7292-9711-8e57e8063536",
  <     "id": "0",
  <     "msg": {
  <       "message": "Reconnecting... 5/5",
  <       "status_code": 401,
  <       "type": "stream_error"
  <     }
  <   }
  < }
  < {
  <   "method": "codex/event/error",
  <   "params": {
  <     "conversationId": "019a9a32-f576-7292-9711-8e57e8063536",
  <     "id": "0",
  <     "msg": {
  <       "message": "exceeded retry limit, last status: 401 Unauthorized, request id: 9a0cb03a485067f7-SJC",
  <       "status_code": 401,
  <       "type": "error"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-19 19:51:21 +00:00
  c2ec477d93