Cross-thread orchestration cannot resolve pending request_user_input

Start by tracing the shipped cross-thread orchestration surface and the app-server request_user_input response lifecycle named in the issue. Use the acceptance criteria to define completion: an authorized coordinator resolves one valid pending request, rejects invalid or stale targets, records both-task attribution, emits serverRequest/resolved, and leaves ordinary messages non-resolving.

Summary

Codex Desktop cross-thread tools can send text to another task, but they cannot resolve a structured request_user_input that is already pending in that task.

For example, task B can be blocked in waitingOnUserInput. Task A can call send_message_to_thread with text that exactly matches one of the displayed choices, but the message is only delivered as text. It does not answer the pending tool request, and task B remains blocked until the user opens that task and clicks the control.

This makes durable task orchestration stop at every structured input gate, even when the user has explicitly authorized task A to coordinate task B.

Requested native capability

Add a first-party, permissioned cross-thread operation for structured input responses. Possible shapes:

• respond_to_thread_user_input(thread_id, request_id, answers); or
• a typed response mode on send_message_to_thread.

The thread-management surface must also expose enough pending-request metadata for the coordinator to select the exact request and valid options.

This is not a request to treat ordinary prose as approval. A structured response must:

• target one exact thread and pending request;
• use the request's declared answer schema;
• reject stale, completed, or mismatched requests;
• preserve normal user and thread permission boundaries;
• produce an audit record in both tasks;
• emit the normal serverRequest/resolved lifecycle event;
• allow the blocked target turn to continue without requiring manual navigation.

Acceptance criteria

1. Task B enters waitingOnUserInput with a two-option request_user_input.
2. An authorized task A can inspect the pending request and submit one valid option through a typed cross-thread API.
3. The exact request resolves and task B continues.
4. Sending the same words as an ordinary message does not implicitly resolve or authorize anything.
5. Wrong-thread, wrong-request, invalid-option, duplicate, and stale responses fail clearly.
6. The UI shows who answered and from which task.

Related issues

These are adjacent but do not provide this capability:

• #36843 proposes typed cross-thread events and authority metadata, but not resolution of a pending structured input request.
• #23664 covers visibility of child approval prompts.
• #31565 covers unanswerable delegated MCP approval elicitations.
• #13289 covers subagents becoming stuck on request_user_input.

The missing piece is a native bridge between the shipped cross-thread orchestration surface and the app-server's structured request_user_input response lifecycle.