175 Commits

• 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
• Stop client from being state carrier (#10595)

  I'd like to make client session wide. This requires shedding all random
  state it has to carry.

  pakrym-oai · 2026-02-04 09:05:37 -08:00
  7f20357611
• feat: land unified_exec (#10641)

  Land `unified_exec` for all non-windows OS

  jif-oai · 2026-02-04 16:39:41 +00:00
  49dd67a260
• Improve Default mode prompt (less confusion with Plan mode) (#10545)

  ## Summary
  
  This PR updates `request_user_input` behavior and Default-mode guidance
  to match current collaboration-mode semantics and reduce model
  confusion.
  
  ## Why
  
  - `request_user_input` should be explicitly documented as **Plan-only**.
  - Tool description and runtime availability checks should be driven by
  the **same centralized mode policy**.
  - Default mode prompt needed stronger execution guidance and explicit
  instruction that `request_user_input` is unavailable.
  - Error messages should report the **actual mode name** (not aliases
  that can read as misleading).
  
  ## What changed
  
  - Centralized `request_user_input` mode policy in `core` handler logic:
    - Added a single allowed-modes config (`Plan` only).
    - Reused that policy for:
      - runtime rejection messaging
      - tool description text
  - Updated tool description to include availability constraint:
    - `"This tool is only available in Plan mode."`
  - Updated runtime rejection behavior:
    - `Default` -> `"request_user_input is unavailable in Default mode"`
    - `Execute` -> `"request_user_input is unavailable in Execute mode"`
  - `PairProgramming` -> `"request_user_input is unavailable in Pair
  Programming mode"`
  - Strengthened Default collaboration prompt:
    - Added explicit execution-first behavior
    - Added assumptions-first guidance
    - Added explicit `request_user_input` unavailability instruction
    - Added concise progress-reporting expectations
  - Simplified formatting implementation:
    - Inlined allowed-mode name collection into `format_allowed_modes()`
  - Kept `format_allowed_modes()` output for 3+ modes as CSV style
  (`modes: a,b,c`)

  Charley Cunningham · 2026-02-03 12:08:38 -08:00
  998eb8f32b
• Inject CODEX_THREAD_ID into the terminal environment (#10096)

  Inject CODEX_THREAD_ID (when applicable) into the terminal environment
  so that the agent (and skills) can refer to the current thread / session
  ID.
  
  Discussion:
  https://openai.slack.com/archives/C095U48JNL9/p1769542492067109

  Max Johnson · 2026-02-03 11:31:12 -08:00
  66b196a725
• Enable parallel shell tools (#10505)

  Summary
  - mark the shell-related tools as supporting parallel tool calls so
  exec_command, shell_command, etc. can run concurrently
  - update expectations in tool parallelism tests to reflect the new
  parallel behavior
  - drop the unused serial duration helper from the suite
  
  Testing
  - Not run (not requested)

  jif-oai · 2026-02-03 18:05:02 +00:00
  33dc93e4d2
• 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
• chore: nuke chat/completions API (#10157)
  jif-oai · 2026-02-03 11:31:57 +00:00
  d2394a2494
• 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
• Do not append items on override turn context (#10354)
  pakrym-oai · 2026-02-01 18:51:26 -08:00
  03fcd12e77
• feat(core) Smart approvals on (#10286)

  ## Summary
  Turn on Smart Approvals by default
  
  ## Testing
   - [x] Updated unit tests

  Dylan Hurd · 2026-01-30 23:12:25 -07:00
  a8c9e386e7
• 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
• Chore: plan mode do not include free form question and always include isOther (#10210)

  We should never ask a freeform question when planning and we should
  always include isOther as an escape hatch.

  Shijie Rao · 2026-01-30 01:19:24 -08:00
  a0ccef9d5c
• MCP tool call approval (simplified version) (#10200)

  Add elicitation approval request for MCP tool call requests.

  Matthew Zeng · 2026-01-29 23:40:32 -08:00
  34f89b12d0
• Better handling skill depdenencies on ENV VAR. (#9017)

  An experimental flow for env var skill dependencies. Skills can now
  declare required env vars in SKILL.md; if missing, the CLI prompts the
  user to get the value, and Core will store it in memory (eventually to a
  local persistent store)
  <img width="790" height="169" alt="image"
  src="https://github.com/user-attachments/assets/cd928918-9403-43cb-a7e7-b8d59bcccd9a"
  />

  xl-openai · 2026-01-29 14:13:30 -05:00
  bdd8a7d58b
• Fall back to http when websockets fail (#10139)

  I expect not all proxies work with websockets, fall back to http if
  websockets fail.

  pakrym-oai · 2026-01-29 10:36:21 -08:00
  3b1cddf001
• feat(core) RequestRule (#9489)

  ## Summary
  Instead of trying to derive the prefix_rule for a command mechanically,
  let's let the model decide for us.
  
  ## Testing
  - [x] tested locally

  Dylan Hurd · 2026-01-28 08:43:17 +00:00
  996e09ca24
• fix: enable per-turn updates to web search mode (#10040)

  web_search can now be updated per-turn, for things like changes to
  sandbox policy.
  
  `SandboxPolicy::DangerFullAccess` now sets web_search to `live`, and the
  default is still `cached`.
  
  Added integration tests.

  sayan-oai · 2026-01-27 18:09:29 -08:00
  a90ab789c2
• remove sandbox globals. (#9797)

  Threads sandbox updates through OverrideTurnContext for active turn
  Passes computed sandbox type into safety/exec

  iceweasel-oai · 2026-01-27 11:04:23 -08:00
  c40ad65bd8
• nit: better tool description (#9988)
  jif-oai · 2026-01-27 12:46:51 +00:00
  742f086ee6
• make cached web_search client-side default (#9974)

  [Experiment](https://console.statsig.com/50aWbk2p4R76rNX9lN5VUw/experiments/codex_web_search_rollout/summary)
  for default cached `web_search` completed; cached chosen as default.
  
  Update client to reflect that.

  sayan-oai · 2026-01-26 21:25:40 -08:00
  0adcd8aa86
• Reject request_user_input outside Plan/Pair (#9955)

  ## Context
  
  Previous work in https://github.com/openai/codex/pull/9560 only rejected
  `request_user_input` in Execute and Custom modes. Since then, additional
  modes
  (e.g., Code) were added, so the guard should be mode-agnostic.
  
  ## What changed
  
  - Switch the handler to an allowlist: only Plan and PairProgramming are
  allowed
  - Return the same error for any other mode (including Code)
  - Add a Code-mode rejection test alongside the existing Execute/Custom
  tests
  
  ## Why
  
  This prevents `request_user_input` from being used in modes where it is
  not
  intended, even as new modes are introduced.

  Charley Cunningham · 2026-01-26 17:12:17 -08:00
  47aa1f3b6a
• fix: attempt to reduce high cpu usage when using collab (#9776)

  Reproduce with a prompt like this with collab enabled:
  ```
  Examine the code at <some subdirectory with a deeply nested project>.  Find the most urgent issue to resolve and describe it to me.
  ```
  
  Existing behavior causes the top-level agent to busy wait on subagents.

  Gene Oden · 2026-01-26 10:07:25 -08:00
  375a5ef051
• Feat: add isOther to question returned by request user input tool (#9890)

  ### Summary
  Add `isOther` to question object from request_user_input tool input and
  remove `other` option from the tool prompt to better handle tool input.

  Shijie Rao · 2026-01-26 09:52:38 -08:00
  3ba702c5b6
• feat: disable collab at max depth (#9899)
  jif-oai · 2026-01-26 17:05:36 +00:00
  70d5959398
• feat: dynamic tools injection (#9539)

  ## Summary
  Add dynamic tool injection to thread startup in API v2, wire dynamic
  tool calls through the app server to clients, and plumb responses back
  into the model tool pipeline.
  
  ### Flow (high level)
  - Thread start injects `dynamic_tools` into the model tool list for that
  thread (validation is done here).
  - When the model emits a tool call for one of those names, core raises a
  `DynamicToolCallRequest` event.
  - The app server forwards it to the client as `item/tool/call`, waits
  for the client’s response, then submits a `DynamicToolResponse` back to
  core.
  - Core turns that into a `function_call_output` in the next model
  request so the model can continue.
  
  ### What changed
  - Added dynamic tool specs to v2 thread start params and protocol types;
  introduced `item/tool/call` (request/response) for dynamic tool
  execution.
  - Core now registers dynamic tool specs at request time and routes those
  calls via a new dynamic tool handler.
  - App server validates tool names/schemas, forwards dynamic tool call
  requests to clients, and publishes tool outputs back into the session.
  - Integration tests

  jif-oai · 2026-01-26 10:06:44 +00:00
  d594693d1a
• feat: cap number of agents (#9855)

  Adding more guards to agent:
  * Max depth or 1 (i.e. a sub-agent can't spawn another one)
  * Max 12 sub-agents in total

  jif-oai · 2026-01-25 14:57:22 +00:00
  73b5274443
• feat: add thread spawn source for collab tools (#9769)
  jif-oai · 2026-01-24 14:21:34 +00:00
  515ac2cd19
• change collaboration mode to struct (#9793)

  Shouldn't cause behavioral change

  Ahmed Ibrahim · 2026-01-23 17:00:23 -08:00
  69cfc73dc6
• feat: async shell snapshot (#9600)
  jif-oai · 2026-01-21 10:41:13 +00:00
  b75024c465
• Reject ask user question tool in Execute and Custom (#9560)

  ## Summary
  - Keep `request_user_input` in the tool list but reject it at runtime in
  Execute/Custom modes with a clear model-facing error.
  - Add a session accessor for current collaboration mode and enforce the
  gate in the request_user_input handler.
  - Update core/app-server tests to use Plan mode for success and add
  Execute/Custom rejection coverage.

  charley-oai · 2026-01-20 18:32:17 -08:00
  0523a259c8
• fix(core) Preserve base_instructions in SessionMeta (#9427)

  ## Summary
  This PR consolidates base_instructions onto SessionMeta /
  SessionConfiguration, so we ensure `base_instructions` is set once per
  session and should be (mostly) immutable, unless:
  - overridden by config on resume / fork
  - sub-agent tasks, like review or collab
  
  
  In a future PR, we should convert all references to `base_instructions`
  to consistently used the typed struct, so it's less likely that we put
  other strings there. See #9423. However, this PR is already quite
  complex, so I'm deferring that to a follow-up.
  
  ## Testing
  - [x] Added a resume test to assert that instructions are preserved. In
  particular, `resume_switches_models_preserves_base_instructions` fails
  against main.
  
  Existing test coverage thats assert base instructions are preserved
  across multiple requests in a session:
  - Manual compact keeps baseline instructions:
  core/tests/suite/compact.rs:199
  - Auto-compact keeps baseline instructions:
  core/tests/suite/compact.rs:1142
  - Prompt caching reuses the same instructions across two requests:
  core/tests/suite/prompt_caching.rs:150 and
  core/tests/suite/prompt_caching.rs:157
  - Prompt caching with explicit expected string across two requests:
  core/tests/suite/prompt_caching.rs:213 and
  core/tests/suite/prompt_caching.rs:222
  - Resume with model switch keeps original instructions:
  core/tests/suite/resume.rs:136
  - Compact/resume/fork uses request 0 instructions for later expected
  payloads: core/tests/suite/compact_resume_fork.rs:215

  Dylan Hurd · 2026-01-19 21:59:36 -08:00
  675f165c56
• Feat: request user input tool (#9472)

  ### Summary
  * Add `requestUserInput` tool that the model can use for gather
  feedback/asking question mid turn.
  
  
  ### Tool input schema
  ```
  {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "requestUserInput input",
    "type": "object",
    "additionalProperties": false,
    "required": ["questions"],
    "properties": {
      "questions": {
        "type": "array",
        "description": "Questions to show the user (1-3). Prefer 1 unless multiple independent decisions block progress.",
        "minItems": 1,
        "maxItems": 3,
        "items": {
          "type": "object",
          "additionalProperties": false,
          "required": ["id", "header", "question"],
          "properties": {
            "id": {
              "type": "string",
              "description": "Stable identifier for mapping answers (snake_case)."
            },
            "header": {
              "type": "string",
              "description": "Short header label shown in the UI (12 or fewer chars)."
            },
            "question": {
              "type": "string",
              "description": "Single-sentence prompt shown to the user."
            },
            "options": {
              "type": "array",
              "description": "Optional 2-3 mutually exclusive choices. Put the recommended option first and suffix its label with \"(Recommended)\". Only include \"Other\" option if we want to include a free form option. If the question is free form in nature, do not include any option.",
              "minItems": 2,
              "maxItems": 3,
              "items": {
                "type": "object",
                "additionalProperties": false,
                "required": ["value", "label", "description"],
                "properties": {
                  "value": {
                    "type": "string",
                    "description": "Machine-readable value (snake_case)."
                  },
                  "label": {
                    "type": "string",
                    "description": "User-facing label (1-5 words)."
                  },
                  "description": {
                    "type": "string",
                    "description": "One short sentence explaining impact/tradeoff if selected."
                  }
                }
              }
            }
          }
        }
      }
    }
  }
  ```
  
  ### Tool output schema
  ```
  {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "requestUserInput output",
    "type": "object",
    "additionalProperties": false,
    "required": ["answers"],
    "properties": {
      "answers": {
        "type": "object",
        "description": "Map of question id to user answer.",
        "additionalProperties": {
          "type": "object",
          "additionalProperties": false,
          "required": ["selected"],
          "properties": {
            "selected": {
              "type": "array",
              "items": { "type": "string" }
            },
            "other": {
              "type": ["string", "null"]
            }
          }
        }
      }
    }
  }
  ```

  Shijie Rao · 2026-01-19 10:17:30 -08:00
  57ec3a8277
• chore: upgrade to Rust 1.92.0 (#8860)

  **Summary**
  - Upgrade Rust toolchain used by CI to 1.92.0.
  - Address new clippy `derivable_impls` warnings by deriving `Default`
  for enums across protocol, core, backend openapi models, and
  windows-sandbox setup.
  - Tidy up related test/config behavior (originator header handling, env
  override cleanup) and remove a now-unused assignment in TUI/TUI2 render
  layout.
  
  **Testing**
  - `just fmt`
  - `just fix -p codex-tui`
  - `just fix -p codex-tui2`
  - `just fix -p codex-windows-sandbox`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-tui2`
  - `cargo test -p codex-windows-sandbox`
  - `cargo test -p codex-core --test all`
  - `cargo test -p codex-app-server --test all`
  - `cargo test -p codex-mcp-server --test all`
  - `cargo test --all-features`

  viyatb-oai · 2026-01-16 11:12:52 -08:00
  f89a40a849
• chore: close pipe on non-pty processes (#9369)

  Closing the STDIN of piped process when starting them to avoid commands
  like `rg` to wait for content on STDIN and hangs for ever

  jif-oai · 2026-01-16 15:54:32 +01:00
  1668ca726f
• feat: collab wait multiple IDs (#9294)
  jif-oai · 2026-01-16 12:05:04 +01:00
  c576756c81
• [search] allow explicitly disabling web search (#9249)

  moving `web_search` rollout serverside, so need a way to explicitly
  disable search + signal eligibility from the client.
  
  - Add `x‑oai‑web‑search‑eligible` header that signifies whether the
  request can have web search.
  - Only attach the `web_search` tool when the resolved `WebSearchMode` is
  `Live` or `Cached`.

  sayan-oai · 2026-01-15 11:28:57 -08:00
  169201b1b5
• feat: add interrupt capabilities to send_input (#9276)
  jif-oai · 2026-01-15 14:59:07 +00:00
  faeb08c1e1
• feat: add agent roles to collab tools (#9275)

  Add `agent_type` parameter to the collab tool `spawn_agent` that
  contains a preset to apply on the config when spawning this agent

  jif-oai · 2026-01-15 13:33:52 +00:00
  05b960671d
• add WebSearchMode enum (#9216)

  ### What
  Add `WebSearchMode` enum (disabled, cached live, defaults to cached) to
  config + V2 protocol. This enum takes precedence over legacy flags:
  `web_search_cached`, `web_search_request`, and `tools.web_search`.
  
  Keep `--search` as live.
  
  ### Tests
  Added tests

  sayan-oai · 2026-01-14 12:51:42 -08:00
  5e426ac270
• feat: adding piped process to replace PTY when needed (#8797)
  jif-oai · 2026-01-14 18:44:04 +00:00
  577e1fd1b2
• feat: emit events around collab tools (#9095)

  Emit the following events around the collab tools. On the `app-server`
  this will be under `item/started` and `item/completed`
  ```
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabAgentSpawnBeginEvent {
      /// Identifier for the collab tool call.
      pub call_id: String,
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Initial prompt sent to the agent. Can be empty to prevent CoT leaking at the
      /// beginning.
      pub prompt: String,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabAgentSpawnEndEvent {
      /// Identifier for the collab tool call.
      pub call_id: String,
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the newly spawned agent, if it was created.
      pub new_thread_id: Option<ThreadId>,
      /// Initial prompt sent to the agent. Can be empty to prevent CoT leaking at the
      /// beginning.
      pub prompt: String,
      /// Last known status of the new agent reported to the sender agent.
      pub status: AgentStatus,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabAgentInteractionBeginEvent {
      /// Identifier for the collab tool call.
      pub call_id: String,
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the receiver.
      pub receiver_thread_id: ThreadId,
      /// Prompt sent from the sender to the receiver. Can be empty to prevent CoT
      /// leaking at the beginning.
      pub prompt: String,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabAgentInteractionEndEvent {
      /// Identifier for the collab tool call.
      pub call_id: String,
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the receiver.
      pub receiver_thread_id: ThreadId,
      /// Prompt sent from the sender to the receiver. Can be empty to prevent CoT
      /// leaking at the beginning.
      pub prompt: String,
      /// Last known status of the receiver agent reported to the sender agent.
      pub status: AgentStatus,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabWaitingBeginEvent {
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the receiver.
      pub receiver_thread_id: ThreadId,
      /// ID of the waiting call.
      pub call_id: String,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabWaitingEndEvent {
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the receiver.
      pub receiver_thread_id: ThreadId,
      /// ID of the waiting call.
      pub call_id: String,
      /// Last known status of the receiver agent reported to the sender agent.
      pub status: AgentStatus,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabCloseBeginEvent {
      /// Identifier for the collab tool call.
      pub call_id: String,
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the receiver.
      pub receiver_thread_id: ThreadId,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, PartialEq, JsonSchema, TS)]
  pub struct CollabCloseEndEvent {
      /// Identifier for the collab tool call.
      pub call_id: String,
      /// Thread ID of the sender.
      pub sender_thread_id: ThreadId,
      /// Thread ID of the receiver.
      pub receiver_thread_id: ThreadId,
      /// Last known status of the receiver agent reported to the sender agent before
      /// the close.
      pub status: AgentStatus,
  }
  ```

  jif-oai · 2026-01-14 17:55:57 +00:00
  6a939ed7a4
• feat: add auto refresh on thread listeners (#9105)

  This PR is in the scope of multi-agent work. 
  
  An agent (=thread) can now spawn other agents. Those other agents are
  not attached to any clients. We need a way to make sure that the clients
  are aware of the new threads to look at (for approval for example). This
  PR adds a channel to the `ThreadManager` that pushes the ID of those
  newly created agents such that the client (here the app-server) can also
  subscribe to those ones.

  jif-oai · 2026-01-14 16:26:01 +00:00
  bcd7858ced
• feat: only source shell snapshot if the file exists (#9197)
  jif-oai · 2026-01-14 01:28:25 -08:00
  bc6d9ef6fc
• chore: clarify default shell for unified_exec (#8997)

  The description of the `shell` arg for `exec_command` states the default
  is `/bin/bash`, but AFAICT it's the user's default shell.
  
  Default logic
  [here](https://github.com/openai/codex/blob/2a06d64bc996e4d848b95285700b195c2852a42f/codex-rs/core/src/tools/handlers/unified_exec.rs#L123).
  
  EDIT: #9004 has an alternative where we inform the model of the default
  shell itself.

  sayan-oai · 2026-01-13 21:37:41 -08:00
  5675af5190
• nit: collab send input cleaning (#9147)
  jif-oai · 2026-01-13 15:15:41 +00:00
  97f1f20edb
• chore: better error handling on collab tools (#9143)
  jif-oai · 2026-01-13 13:56:11 +00:00
  3b8d79ee11
• nit: add docstring (#9099)

  Add docstring on `ToolHandler` trait

  jif-oai · 2026-01-12 17:40:52 +00:00
  898e5f82f0
• feat: add close tool implementation for collab (#9090)

  Pretty straight forward. A known follow-up will be to drop it from the
  AgentControl

  jif-oai · 2026-01-12 13:21:46 +00:00
  9659583559
• feat: add wait tool implementation for collab (#9088)

  Add implementation for the `wait` tool.
  
  For this we consider all status different from `PendingInit` and
  `Running` as terminal. The `wait` tool call will return either after a
  given timeout or when the tool reaches a non-terminal status.
  
  A few points to note:
  * The usage of a channel is preferred to prevent some races (just
  looping on `get_status()` could "miss" a terminal status)
  * The order of operations is very important, we need to first subscribe
  and then check the last known status to prevent race conditions
  * If the channel gets dropped, we return an error on purpose

  jif-oai · 2026-01-12 12:16:24 +00:00
  623707ab58