Cross-thread orchestration cannot resolve pending request_user_input

[devansh-jain-18]

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:

• Follow-up: typed, evidence-aware CrossThreadEvent contract for safe peer-thread orchestration #36843 proposes typed cross-thread events and authority metadata, but not resolution of a pending structured input request.
• Subagents requiring approval to run command pop-up does not consistently display on initial ask #23664 covers visibility of child approval prompts.
• Review-delegate MCP tool calls hang forever: approval elicitation is unanswerable in delegated sub-agents (forward_events has no ElicitationRequest arm) #31565 covers unanswerable delegated MCP approval elicitations.
• Forked Subagents Using request_user_input #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.