Shijie Rao

This commit introduces a **new capability** to the **`app-server`**'s **`thread/resume`** endpoint, allowing it to reuse previously persisted `model` and `model_reasoning_effort` metadata from SQLite. This change ensures that **resumed threads** maintain their original model settings, preventing configuration drift and providing a more consistent experience. The logic, primarily implemented in `codex_message_processor.rs`, prioritizes explicit resume overrides, then persisted metadata, and finally current configuration. The **`README.md`** has also been updated to document this new fallback behavior for thread resumption.

This **new feature** introduces the persistence of the latest `model` and `reasoning_effort` for threads within the **`codex-rs` state module's persistence layer**. It **modifies the SQLite database schema** by adding `model` and `reasoning_effort` columns to the `threads` table and updates internal data structures like `ThreadMetadata` and `ThreadRow`. The commit also updates the `apply_turn_context`, `insert_thread`, and `upsert_thread` functions to **store these new values** from the turn context into the database. This foundational change enables future functionality where `thread/resume` can retrieve these persisted values if no override is provided, improving the consistency of thread context.

This commit introduces a **new capability** to the **`model/list` endpoint** by integrating `upgradeInfo` metadata directly into the `Model` schema. It updates the **`app-server-protocol`** with new JSON, TypeScript, and Rust definitions for `ModelUpgradeInfo` and embeds this information within the existing `Model` structures. The **`app-server`** logic is enhanced to populate this new `upgrade_info` field when converting `ModelPreset` objects, ensuring comprehensive data is available. This change provides clients consuming the `model/list` API with crucial details about model upgrade status, facilitating better model management and user experience. Documentation for the `app-server` and MCP interface, along with relevant tests, has been updated to reflect this enhancement.

This commit **refactors** the **model downgrade safety check** mechanism, primarily affecting the **`codex-api` SSE response handling** and **`codex-core` model comparison logic**. It now **relies exclusively on the `OpenAI-Model` header** for Server-Sent Events (SSE) and top-level events for WebSockets to determine the server's model, removing a previous response body check that caused false positives. The `ResponsesStreamEvent::response_model` method was refactored to support this, and the `is_model_downgrade` function was **fixed** to perform case-insensitive comparisons. This **maintenance** and **bug fix** improves the **accuracy and reliability** of model downgrade warnings, ensuring correct slug names are always used.

This commit introduces a **new capability** by adding a dedicated `model/rerouted` notification and associated event types to the **application server protocol**. It defines `ModelRerouteEventMsg` and `ModelRerouteReason` across JSON schemas, TypeScript, and Rust types, allowing for explicit communication of model reroute events. The **core event handling** in `codex.rs` is updated to emit this new event, and the **application server** now processes it as a `ModelReroutedNotification`, replacing previous warning-based logic for this specific scenario. This **protocol extension** enables downstream clients to render model reroute information more accurately and supports future system logic, with initial handling added to various components without immediate user-facing changes. Extensive **testing** and **documentation** for the new notification are also included.

This commit **fixes a critical bug** in the **parallel tool call execution approval system** where `exec` commands were incorrectly approved at a turn level, rather than per individual request. To resolve this, the system now consistently uses a unique `call_id` (or `request_id`/`approval_id`) to identify and approve specific `exec` and `patch` requests, with `turn_id` also being passed for `exec` approvals to maintain context. This **refactoring** primarily impacts the **`codex-rs/app-server`**, **`codex-rs/core`**, **`codex-rs/mcp-server`**, and **`codex-rs/tui`** components, requiring updates to the **`codex-rs/protocol`** to include `turn_id` in `ExecApproval` operations. This ensures that **command execution approvals** are precise and granular, preventing unintended approvals and significantly enhancing the reliability and security of the system when handling multiple concurrent tool calls. Corresponding **test suites** have been updated across various modules to validate the new `call_id`-based approval logic.

This commit introduces a **new feature** by adding an optional `upgrade` field to the **`Model` definition** within the `app-server-protocol`. This enhancement to the **`model/list` API endpoint** allows the application server to dynamically communicate whether a specific model has an available upgrade. The change involves updating the **protocol schemas**, the Rust `Model` struct in `v2.rs`, and the `model_from_preset` function in the **`app-server`** to populate this new field. This enables client applications to display an **upgrade banner** based on server-provided information, with corresponding updates to documentation and tests.

This commit **enhances** the **`request_user_input` tool** by enforcing that all user input questions must now include predefined options, particularly relevant for "plan mode" interactions. It **refactors** the system to **automatically provide an "Other" free-form input option**, removing the need for an explicit `isOther` field in the tool specification and ensuring an escape hatch is always available. This change prevents direct free-form questions and standardizes user input handling, impacting the `app-server-protocol` definition, the core `request_user_input` handler, and associated documentation and tests.

This commit introduces a **new capability** to the **`request_user_input` tool** by adding an `is_other` boolean field to its question object, improving the semantic handling of free-form user input. This **feature enhancement** allows the system to explicitly identify questions that permit an "other" or custom response, rather than relying on an explicit "other" option within the prompt itself. The change impacts **protocol definitions** (`v2.rs`, `request_user_input.rs`), the **app server's event handling** (`apply_bespoke_event_handling`), and the **tool specification** (`create_request_user_input_tool`), ensuring consistent data modeling and communication. Corresponding **documentation** and **test cases** have been updated to reflect this new property, streamlining how user input is requested and processed.

This commit **enhances the command execution approval protocol** by adding critical command details to the `CommandExecutionRequestApprovalParams` structure. It introduces `command`, `cwd`, and `command_actions` fields to `codex-rs/app-server-protocol/src/protocol/v2.rs`, which are then populated by the `app-server` in `bespoke_event_handling.rs`. This **bug fix** addresses an issue where pending approval requests in **VSCE and the main application** lacked sufficient information to display the actual command, improving the clarity and completeness of approval prompts for users. The `app-server-test-client` and `README.md` are also updated to reflect these changes, ensuring downstream consumers can accurately render command execution requests.

This commit **refactors** the **user input protocol** to simplify how responses are structured, specifically impacting **plan mode output**. It unifies `selected` and `other` fields into a single `answers` vector within the `RequestUserInputAnswer` structure, streamlining data handling across the `app-server-protocol` and `protocol` crates. Consequently, the **Terminal User Interface (TUI)** for user input and the `app-server`'s response handling are updated to align with this new format. Additionally, the **plan template** (`core/templates/collaboration_mode/plan.md`) is updated to clarify `request_user_input` usage and simplify the overall plan output, ensuring consistency and improved clarity for users. This change primarily involves **refactoring** and **documentation updates** to enhance the system's internal consistency and user experience.

This commit introduces a **feature enhancement** to the **`collaboration_mode`** by updating the `plan.md` template. The updated template now provides explicit instructions for the AI to utilize `request_user_input` for interactive planning and mandates that the plan output be in a **JSON format** under a `plan` key. Additionally, it temporarily **removes the direct writing of `PLAN.md`** to the file system, addressing potential sandbox environment issues. This change aims to improve the structure and interactivity of AI-generated plans within the system, streamlining the planning phase.

This commit introduces a **new capability** by adding the `requestUserInput` tool, enabling the model to proactively ask users questions and gather feedback mid-turn. This **feature** significantly enhances interactive model-user conversations by allowing dynamic clarification and decision-making. The implementation involves extensive updates across the **core model interaction logic**, **app server event handling**, and **shared protocol definitions**, including new data structures for questions, options, and answers. It also includes comprehensive **tool specifications**, **state management** for pending requests, and **extensive testing** to ensure robust integration and functionality.

This commit introduces a **new capability** to **hot reload MCP (Message Control Plane) server configurations** dynamically across the application. It adds an `mcpServer/refresh` command to the **`app-server`** that, upon receipt, signals the **`codex core`** to update a `pending_mcp_server_refresh_config` state. During subsequent turn processing, the core orchestrates the reinitialization of the **MCP server manager** on each active thread, leveraging the `thread_manager` to propagate the refresh request. This enhancement significantly improves operational flexibility by allowing administrators to apply configuration changes without requiring a full application restart.

This commit introduces a **new capability** by implementing a `configRequirements/read` API endpoint in the **App Server**, enabling clients to fetch configuration requirements defined in `requirement.toml` files. It extends the **core configuration system** to load, store, and expose these requirements, defining new protocol types like `ConfigRequirementsRead` and `ConfigRequirements` for this data exchange. This feature allows downstream clients, specifically **VSCE**, to dynamically adapt their user interface, such as conditionally disabling the agent mode dropdown selection or correctly setting default values, based on server-side configurations. The work spans across the `app-server-protocol`, `app-server`, and `core` modules to establish this new communication and data handling.

This commit introduces **output size and delta limits** for `exec` commands within the **unified exec** system, specifically targeting the `codex-rs/core/src/unified_exec/async_watcher.rs` module. This is a **bug fix** designed to prevent the **VSCE UI** from becoming sluggish or crashing when processing excessively large shell command outputs, a common issue in monorepos or large projects. By implementing these limits and adding a new helper function for `split_valid_utf8_prefix_with_max`, the change ensures that the deltas sent to the UI are manageable, significantly improving the stability and responsiveness of the user interface.

This commit performs a **maintenance chore** by **removing the experimental `rmcp_client` feature flag** and its associated checks from the codebase. It **refactors the CLI client logic** in `codex-rs/cli/src/mcp_cmd.rs`, specifically for `run_add` and `run_login` commands, to directly enable OAuth login without requiring the experimental flag. Consequently, the **Rust MCP client** is now the default and only client used for streamable HTTP connections, simplifying the configuration and user experience. The **project documentation** in `docs/config.md` is updated to reflect this change, removing references to the deprecated feature flag.

This commit introduces a **new capability** by making the `list_models` function within the **`app-server`** non-blocking, allowing for asynchronous model retrieval. It refactors `codex-rs/app-server/src/codex_message_processor.rs` to execute `list_models` in a separate Tokio task and forces the system's configuration to utilize **remote models**, specifically fetching the `codex-auto` model list. This change empowers consumers, such as extensions, to manage the flow of model listing independently, improving responsiveness. Corresponding tests in `codex-rs/app-server/tests/suite/v2/model_list.rs` were updated to reflect the new expected remote model configuration and order.

This commit **refactors** the **`codex_message_processor`** within the `app-server` to enhance concurrency and responsiveness. The `listMcpServerStatus` function has been updated to be **non-blocking** by wrapping its logic with `tokio::spawn`, effectively moving its execution to a new asynchronous task. This **asynchronous optimization** prevents the main thread from being blocked during MCP server status checks, improving the overall performance of the `codex-rs` application server. The introduction of `list_mcp_server_status_task` encapsulates the original blocking logic, ensuring smoother operation and better resource utilization.

This commit performs a **significant refactoring** within the **`app-server`** and **`app-server-protocol`** modules by **renaming** the API endpoint and associated types for listing MCP servers. Specifically, the `listMcpServers` endpoint and its related structures like `McpServersList`, `ListMcpServersParams`, `McpServer`, and `ListMcpServersResponse` have been updated to `listMcpServerStatus`, `McpServerStatusList`, `ListMcpServerStatusParams`, `McpServerStatus`, and `ListMcpServerStatusResponse` respectively. This change improves the semantic clarity of the **MCP server listing functionality**, now explicitly indicating that it retrieves server *statuses*. The **API documentation** in `README.md` has also been updated to reflect the new `mcpServerStatus/list` endpoint, ensuring external consumers are aware of the revised interface.