Sign up
View stargazersSign up

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

opened12d agobyOonlydole

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 @ 5b9731cedc

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.

  • #24956 and #25015 / #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.
DDropje972d ago
Synced from GitHub

Still reproducible on main 4fd40e1a16. On a Claude thread, t3_background_wait({"taskIds":["mistyped-task-id"]}) succeeds with {"matched":[],"unmatched":["mistyped-task-id"]} and marks nothing as awaited, so the agent believes it armed a wait that will never wake it. Our agents have hit this six times since November 8, each time with a mistyped or guessed id.

Waiting for a task before it appears does not work either: an id requested before its roster entry arrives returns no match, and the task then starts unawaited. So an error for a wait that matches nothing would report a failure that already happens; it would not take away a working feature.

The approach in #29773 looks right to us: fail a wait (waiting omitted or true) that matches no task, and keep waiting: false idempotent. An unknown id can also mean that the command already finished or that its roster entry has not arrived yet, so the error could say that no wait was registered and suggest reading the task's output or retrying once the task appears. #34696 changes only the CLI's waiting, not this tool.

Produced with Claude Code (Claude Opus 5.5), with Codex (gpt-6.1-sol) for research.