18 Commits

• 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
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• 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
• feat: drop agent bus and store the agent status in codex directly (#8788)
  jif-oai · 2026-01-06 19:44:39 +00:00
  188f79afee
• feat: agent controller (#8783)

  Added an agent control plane that lets sessions spawn or message other
  conversations via `AgentControl`.
  
  `AgentBus` (core/src/agent/bus.rs) keeps track of the last known status
  of a conversation.
  
  ConversationManager now holds shared state behind an Arc so AgentControl
  keeps only a weak back-reference, the goal is just to avoid explicit
  cycle reference.
  
  Follow-ups:
  * Build a small tool in the TUI to be able to see every agent and send
  manual message to each of them
  * Handle approval requests in this TUI
  * Add tools to spawn/communicate between agents (see related design)
  * Define agent types

  jif-oai · 2026-01-06 19:08:02 +00:00
  1dd1355df3
• feat: expose outputSchema to user_turn/turn_start app_server API (#8377)

  What changed
  - Added `outputSchema` support to the app-server APIs, mirroring `codex
  exec --output-schema` behavior.
  - V1 `sendUserTurn` now accepts `outputSchema` and constrains the final
  assistant message for that turn.
  - V2 `turn/start` now accepts `outputSchema` and constrains the final
  assistant message for that turn (explicitly per-turn only).
  
  Core behavior
  - `Op::UserTurn` already supported `final_output_json_schema`; now V1
  `sendUserTurn` forwards `outputSchema` into that field.
  - `Op::UserInput` now carries `final_output_json_schema` for per-turn
  settings updates; core maps it into
  `SessionSettingsUpdate.final_output_json_schema` so it applies to the
  created turn context.
  - V2 `turn/start` does NOT persist the schema via `OverrideTurnContext`
  (it’s applied only for the current turn). Other overrides
  (cwd/model/etc) keep their existing persistent behavior.
  
  API / docs
  - `codex-rs/app-server-protocol/src/protocol/v1.rs`: add `output_schema:
  Option<serde_json::Value>` to `SendUserTurnParams` (serialized as
  `outputSchema`).
  - `codex-rs/app-server-protocol/src/protocol/v2.rs`: add `output_schema:
  Option<JsonValue>` to `TurnStartParams` (serialized as `outputSchema`).
  - `codex-rs/app-server/README.md`: document `outputSchema` for
  `turn/start` and clarify it applies only to the current turn.
  - `codex-rs/docs/codex_mcp_interface.md`: document `outputSchema` for v1
  `sendUserTurn` and v2 `turn/start`.
  
  Tests added/updated
  - New app-server integration tests asserting `outputSchema` is forwarded
  into outbound `/responses` requests as `text.format`:
    - `codex-rs/app-server/tests/suite/output_schema.rs`
    - `codex-rs/app-server/tests/suite/v2/output_schema.rs`
  - Added per-turn semantics tests (schema does not leak to the next
  turn):
    - `send_user_turn_output_schema_is_per_turn_v1`
    - `turn_start_output_schema_is_per_turn_v2`
  - Added protocol wire-compat tests for the merged op:
    - serialize omits `final_output_json_schema` when `None`
    - deserialize works when field is missing
    - serialize includes `final_output_json_schema` when `Some(schema)`
  
  Call site updates (high level)
  - Updated all `Op::UserInput { .. }` constructions to include
  `final_output_json_schema`:
    - `codex-rs/app-server/src/codex_message_processor.rs`
    - `codex-rs/core/src/codex_delegate.rs`
    - `codex-rs/mcp-server/src/codex_tool_runner.rs`
    - `codex-rs/tui/src/chatwidget.rs`
    - `codex-rs/tui2/src/chatwidget.rs`
    - plus impacted core tests.
  
  Validation
  - `just fmt`
  - `cargo test -p codex-core`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-mcp-server`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-tui2`
  - `cargo test -p codex-protocol`
  - `cargo clippy --all-features --tests --profile dev --fix -- -D
  warnings`

  Anton Panasenko · 2026-01-05 10:27:00 -08:00
  807f8a43c2
• Account for last token count on resume (#8677)

  last token count in context manager is initialized to 0. Gets populated
  only on events from server.
  
  This PR populates it on resume so we can decide if we need to compact or
  not.

  Ahmed Ibrahim · 2026-01-02 23:20:20 +00:00
  efd2d76484
• Rename OpenAI models to models manager (#8346)

  # 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.

  Ahmed Ibrahim · 2025-12-19 16:20:05 -08:00
  f0dc6fd3c7
• chore: migrate from Config::load_from_base_config_with_overrides to ConfigBuilder (#8276)

  https://github.com/openai/codex/pull/8235 introduced `ConfigBuilder` and
  this PR updates all call non-test call sites to use it instead of
  `Config::load_from_base_config_with_overrides()`.
  
  This is important because `load_from_base_config_with_overrides()` uses
  an empty `ConfigRequirements`, which is a reasonable default for testing
  so the tests are not influenced by the settings on the host. This method
  is now guarded by `#[cfg(test)]` so it cannot be used by business logic.
  
  Because `ConfigBuilder::build()` is `async`, many of the test methods
  had to be migrated to be `async`, as well. On the bright side, this made
  it possible to eliminate a bunch of `block_on_future()` stuff.

  Michael Bolin · 2025-12-18 16:12:52 -08:00
  3d4ced3ff5
• 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
• Removed experimental "command risk assessment" feature (#7799)

  This experimental feature received lukewarm reception during internal
  testing. Removing from the code base.

  Eric Traut · 2025-12-10 09:48:11 -08:00
  c4af707e09
• Refactor execpolicy fallback evaluation (#7544)

  ## Refactor of the `execpolicy` crate
  
  To illustrate why we need this refactor, consider an agent attempting to
  run `apple | rm -rf ./`. Suppose `apple` is allowed by `execpolicy`.
  Before this PR, `execpolicy` would consider `apple` and `pear` and only
  render one rule match: `Allow`. We would skip any heuristics checks on
  `rm -rf ./` and immediately approve `apple | rm -rf ./` to run.
  
  To fix this, we now thread a `fallback` evaluation function into
  `execpolicy` that runs when no `execpolicy` rules match a given command.
  In our example, we would run `fallback` on `rm -rf ./` and prevent
  `apple | rm -rf ./` from being run without approval.

  zhao-oai · 2025-12-03 23:39:48 -08:00
  3d35cb4619
• whitelist command prefix integration in core and tui (#7033)

  this PR enables TUI to approve commands and add their prefixes to an
  allowlist:
  <img width="708" height="605" alt="Screenshot 2025-11-21 at 4 18 07 PM"
  src="https://github.com/user-attachments/assets/56a19893-4553-4770-a881-becf79eeda32"
  />
  
  note: we only show the option to whitelist the command when 
  1) command is not multi-part (e.g `git add -A && git commit -m 'hello
  world'`)
  2) command is not already matched by an existing rule

  zhao-oai · 2025-12-03 23:17:02 -08:00
  e925a380dc
• Migrate model family to models manager (#7565)

  This PR moves `ModelsFamily` to `openai_models`. It also propagates
  `ModelsManager` to session services and use it to drive model family. We
  also make `derive_default_model_family` private because it's a step
  towards what we want: one place that gives model configuration.
  
  This is a second step at having one source of truth for models
  information and config: `ModelsManager`.
  
  Next steps would be to remove `ModelsFamily` from config. That's massive
  because it's being used in 41 occasions mostly pre launching `codex`.
  Also, we need to make `find_family_for_model` private. It's also big
  because it's being used in 21 occasions ~ all tests.

  Ahmed Ibrahim · 2025-12-03 18:49:47 -08:00
  cee37a32b2
• fix: codex delegate cancellation (#7092)
  jif-oai · 2025-11-24 16:59:09 +00:00
  920239f272
• ignore deltas in codex_delegate (#6208)

  ignore legacy deltas in codex-delegate to avoid this
  [issue](https://github.com/openai/codex/pull/6202).

  Ahmed Ibrahim · 2025-11-04 19:21:35 +00:00
  fe54c216a3
• Pass initial history as an optional to codex delegate (#5950)

  This will give us more freedom on controlling the delegation. i.e we can
  fork our history and run `compact`.

  Ahmed Ibrahim · 2025-10-30 07:22:42 -07:00
  5fcc380bd9
• Delegate review to codex instance (#5572)

  In this PR, I am exploring migrating task kind to an invocation of
  Codex. The main reason would be getting rid off multiple
  `ConversationHistory` state and streamlining our context/history
  management.
  
  This approach depends on opening a channel between the sub-codex and
  codex. This channel is responsible for forwarding `interactive`
  (`approvals`) and `non-interactive` events. The `task` is responsible
  for handling those events.
  
  This opens the door for implementing `codex as a tool`, replacing
  `compact` and `review`, and potentially subagents.
  
  One consideration is this code is very similar to `app-server` specially
  in the approval part. If in the future we wanted an interactive
  `sub-codex` we should consider using `codex-mcp`

  Ahmed Ibrahim · 2025-10-29 21:04:25 +00:00
  13e1d0362d