Claude background subagent stays Running in Lineage for hours after its task_notification reports completed#18910

I can't confirm a T3 bug from this yet, so I'm marking it needs-info. It isn't a duplicate of #16355 (nested), #17099 (other provider) or #18877 (session replacement), and none of the open PRs (#16814, #17109, #16609, #17320, #17921) touch this path.

On main (80664d52), a task_notification that arrives while the root is idle is buffered by bufferWakeMessage as long as the session registry still has the subagent as running. A queued mid-run SendMessage doesn't emit task_started, so it doesn't change the registry or runToolUseId. task_updated isn't handled at all. Your sibling task followed the same sequence and settled, and that matches what I see in the code. So the queued SendMessage isn't the cause, and I can't find a path that drops this completion.

To narrow it down:

1. Server log lines (not the provider event log) for this thread between 22:03:45 and 22:05 UTC, especially anything about the wake continuation drain or a subagent update that was skipped.
2. Did the 22:04:49 wake turn finish normally in T3, or did it show an error or get interrupted?
3. Does it still happen on the latest nightly? If you see it again, export the thread's projection rows before using the SendMessage workaround, since that overwrites the stuck row.

Without these, this will close automatically in 14 days.

@juliusmarminge answers, plus what looks like the mechanism.

1. Server log lines, 22:03:45–22:05 UTC. Gone. server.trace.ndjson* rotates in about an hour here and now starts at 03:02 UTC. desktop.trace.ndjson.3 covers the window but has only desktop IPC spans. What survives is the provider event log and the SQLite projections below.

2. Did the 22:04:49 wake turn finish? It never ran. From orchestration_v2_projection_runs for this thread:

The provider log for the same window:

What this looks like:

1. The sibling finished at 21:57:12 with no run open (17 had completed at 21:48). Continuation run 18 started at once, drained the buffer, and the sibling settled.
2. Run 18 never completed in T3. The CLI's later native turns, driven by more task notifications, kept being projected into it for five hours, until the user's message interrupted it at 03:04:16.
3. The stuck subagent finished at 22:04:48, in the gap between two native turns while run 18 was still open. Its notification was buffered and continuation run 19 queued behind 18.
4. The CLI consumed the notification natively in its 22:04:49 turn, inside run 18. Run 19 is still held and never started, so the buffered task_notification never drained and the subagent stayed running.

So the trigger seems to be a background subagent finishing while an earlier wake continuation run is still open. The queued SendMessage is not involved, as you said.

On the same machine, thread 8ad19ec2… has 37 runs queued with queueHeld: true (2026-10-11 18:41 to 2026-10-12 02:12), all with synthetic message:… ids. At least one is a pr-watch wake. It has the same held-queue signature, though I haven't checked whether subagents are involved there.

3. Latest nightly / rows before the workaround. Seen on 0.0.46-nightly.20261010.2935; not retried on a newer nightly yet. The other thread with 19 stuck subagents (screenshot) was cleared the same way before I could export its rows. The run rows above are untouched. I can export them, and the 8ad19ec2… rows, if useful.

Thanks for the report. This is fixed on main in #19196. Please test on the nightly built from main on 2026-10-21, or on the next stable release. If the problem still occurs there, please open a new issue that links to this one, with your version and steps to reproduce it.