Let t3_thread_wait run as a background job so the waiting thread is not stuck in a running turn

[kaovilai]

Problem

When an agent calls t3_thread_wait (or delegate_task with mode: "wait"), the call is a blocking tool call. The MCP handler waits until the other thread's run is terminal or the timeout hits (default 10 minutes, max 1 hour), and the agent cannot continue until the result comes back.

So the waiting thread's run stays running for the whole wait. The composer treats it like any active turn and offers only queue or steer. On Claude, a steer cancels the pending tool before the message lands, so the default send can cut the wait short and the agent sees a refusal-looking tool result. Queue avoids that, but the message sits behind a turn that is only waiting.

Work that is already a background job behaves differently. With an async delegate_task, a running subagent, a monitor or a watched PR, the turn ends. The thread looks idle, the composer sends a normal new turn, and a completion wake resumes the agent later.

What exists today

• Sidebar: a thread blocked only on another thread now shows Waiting instead of Working (Show Waiting, not Working, for a thread blocked on another thread #18711, shipped). The turn is still blocked, so the composer is unchanged.
• Async delegate_task already returns a taskId and wakes the parent on completion.
• Tool results for running tasks tell the agent to end its turn instead of polling.
• Nothing changes how t3_thread_wait itself holds the turn.

Request

Let a wait become a background job instead of a blocking call, so the waiting thread's turn can settle and the composer is idle.

Sketch:

• t3_thread_wait (and delegate_task with mode: "wait") can return immediately with a handle, and the thread is woken when the target run reaches a terminal state. The wake behaves like an async delegate_task completion.
• While waiting, the thread shows up as having pending background work (Waiting on a thread), next to subagents and monitors, with the same Stop affordance.
• The composer then sends a normal new turn. No queue or steer, and no tool cancelled by a steer.
• A short blocking wait stays available for quick mid-turn checks.

Open questions

• Opt-in via a parameter, or the default for waits longer than some threshold?
• Should a message sent to the waiting thread cancel the pending wake, or leave it armed?
• How does this interact with the existing timeout (timedOut=true) and with agents that do not support wake notifications?
• Is it enough to change the tool and the agent instructions, or does the composer also need to treat an active wait tool specially for threads that are already blocked?

Related

• Orchestrator chats: delegate to worker threads without blocking the chat #14762: orchestrator chats that delegate to workers without blocking the chat. Same goal, framed as a new chat mode with worker tools.
• Should a run blocked on foreground subagents read as waiting on subagents? #18499: a run blocked on foreground subagents keeps the composer busy for the same reason.
• Show Waiting, not Working, for a thread blocked on another thread #18711 (closed): Waiting status for a thread blocked on another thread.
• Agent steers on Claude threads cancel tools and look like user refusals #21895: agent steers on Claude cancel running tools.
• Follow-ups: offer non-interrupting mid-turn delivery like Claude Code CLI Enter #24399: non-interrupting mid-turn delivery for follow-ups.
• Let an orchestrator thread hear from its workers, and pass their questions to the user #17212: orchestrator hears from its workers.

Note

Written with Claude Code (model: claude-sonnet-5-5) on behalf of the user.

[royalaid]

Related proposal: #26689 proposes an explicit, bounded wait for threads that end their turn while waiting on other work. It deliberately leaves blocking t3_thread_wait as it is and treats making it asynchronous as this discussion's separate question.