[Bug]: t3_background_wait succeeds when none of its task IDs exist, so agents end their turn and are never woken #29772

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On a Claude thread, have the agent call t3_background_wait with task IDs that are not background tasks on the thread, for example {"taskIds":["placeholder"]} or the ID of a Claude subagent.
2. Read the tool result.

Expected behavior

The call fails and says that none of the IDs is background work T3 can wait on, so the agent knows nothing will wake the thread.

Actual behavior

The call succeeds with {"matched":[],"unmatched":["placeholder"]}. Nothing is marked awaited. Agents read a successful result as "I am now waiting", end the turn, and are never woken.

Two agent sessions from 2026-11-02 show this:

• One agent passed the literal ID placeholder, got a normal result with that ID under unmatched, and ended its turn.
• Another agent called t3_background_wait three times with a background command ID and a Claude subagent ID. Each call returned the subagent ID under unmatched with no error, and the agent wrote "I'll continue when the review comes back." The user had to send "Continue - why did you stop?"

ThreadManagementService.awaitBackgroundTasks returns { matched, unmatched } whether or not anything matched. An empty matched on a wait is never useful to the caller.

Impact

Major degradation or frequent failure

Version or commit

main @ 5b9731c

Environment

Claude provider (Claude Agent SDK) through T3 Code's MCP server

Workaround

The user notices the stalled thread and sends a follow-up message.

Related

• t3_background_wait accepts tasks owned by a foreground native subagent, which are killed when it ends its turn, so the subagent stalls silently #24956 and fix(claude): reject waits on native subagent commands #25015 / fix(server): reject waits on foreground subagent background work #25036: waits on a foreground subagent's own background work come back matched and then die. Those PRs move such IDs to unmatched. A wait where every ID is unmatched still returns success, so an agent in that situation is still told nothing.
• In the second session above, the background command ID matched. Whether a partly matched wait should also warn about the unmatched IDs is a separate question. This issue covers the case where nothing matched.