mirror of
https://github.com/openai/codex.git
synced 2026-04-30 11:21:34 +03:00
926b2f19e8
This adds a first-class server request for MCP server elicitations:
`mcpServer/elicitation/request`.
Until now, MCP elicitation requests only showed up as a raw
`codex/event/elicitation_request` event from core. That made it hard for
v2 clients to handle elicitations using the same request/response flow
as other server-driven interactions (like shell and `apply_patch`
tools).
This also updates the underlying MCP elicitation request handling in
core to pass through the full MCP request (including URL and form data)
so we can expose it properly in app-server.
### Why not `item/mcpToolCall/elicitationRequest`?
This is because MCP elicitations are related to MCP servers first, and
only optionally to a specific MCP tool call.
In the MCP protocol, elicitation is a server-to-client capability: the
server sends `elicitation/create`, and the client replies with an
elicitation result. RMCP models it that way as well.
In practice an elicitation is often triggered by an MCP tool call, but
not always.
### What changed
- add `mcpServer/elicitation/request` to the v2 app-server API
- translate core `codex/event/elicitation_request` events into the new
v2 server request
- map client responses back into `Op::ResolveElicitation` so the MCP
server can continue
- update app-server docs and generated protocol schema
- add an end-to-end app-server test that covers the full round trip
through a real RMCP elicitation flow
- The new test exercises a realistic case where an MCP tool call
triggers an elicitation, the app-server emits
mcpServer/elicitation/request, the client accepts it, and the tool call
resumes and completes successfully.
### app-server API flow
- Client starts a thread with `thread/start`.
- Client starts a turn with `turn/start`.
- App-server sends `item/started` for the `mcpToolCall`.
- While that tool call is in progress, app-server sends
`mcpServer/elicitation/request`.
- Client responds to that request with `{ action: "accept" | "decline" |
"cancel" }`.
- App-server sends `serverRequest/resolved`.
- App-server sends `item/completed` for the mcpToolCall.
- App-server sends `turn/completed`.
- If the turn is interrupted while the elicitation is pending,
app-server still sends `serverRequest/resolved` before the turn
finishes.
41 lines
832 B
Rust
41 lines
832 B
Rust
mod account;
|
|
mod analytics;
|
|
mod app_list;
|
|
mod collaboration_mode_list;
|
|
mod compaction;
|
|
mod config_rpc;
|
|
mod connection_handling_websocket;
|
|
#[cfg(unix)]
|
|
mod connection_handling_websocket_unix;
|
|
mod dynamic_tools;
|
|
mod experimental_api;
|
|
mod experimental_feature_list;
|
|
mod initialize;
|
|
mod mcp_server_elicitation;
|
|
mod model_list;
|
|
mod output_schema;
|
|
mod plan_item;
|
|
mod rate_limits;
|
|
mod realtime_conversation;
|
|
mod request_user_input;
|
|
mod review;
|
|
mod safety_check_downgrade;
|
|
mod skills_list;
|
|
mod thread_archive;
|
|
mod thread_fork;
|
|
mod thread_list;
|
|
mod thread_loaded_list;
|
|
mod thread_metadata_update;
|
|
mod thread_read;
|
|
mod thread_resume;
|
|
mod thread_rollback;
|
|
mod thread_start;
|
|
mod thread_status;
|
|
mod thread_unarchive;
|
|
mod thread_unsubscribe;
|
|
mod turn_interrupt;
|
|
mod turn_start;
|
|
mod turn_start_zsh_fork;
|
|
mod turn_steer;
|
|
mod windows_sandbox_setup;
|