[Bug]: A Claude subagent resumed with SendMessage stays "completed" or "failed" in the Agents panel (regression of #5529)

[Vantrongs]

Before submitting

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

Area

apps/web

Steps to reproduce

1. In a Claude thread, have the agent start a background subagent and let it finish (or fail, for example on the session limit).
2. Have the main agent continue it with SendMessage.
3. Watch the Agents panel while the subagent works.

Expected behavior

The subagent shows as running again, and completes again when the second run ends.

Actual behavior

Same symptom as #5529, which was closed on 2026-08-10; it is back on main.

The subagent runs again, but the Agents panel keeps showing it as completed, with the first run's duration. The same happens after a failure: a subagent stopped by the session limit (Agent terminated early due to an API error: You've hit your session limit) and continued after the reset keeps the red error and the failed status for the whole second run, which in my case lasted 1.5 hours.

Cause

Claude Code does not send a task_updated with status: "running" on resume. It sends a second task_started for the same task_id, with the tool_use_id of the SendMessage call. ClaudeAdapter forwards it as task.started with the new toolUseId.

In packages/client-runtime/src/state/subagentRuntime.ts, foldSubagentActivities, the task.started case treats a start that arrives after a terminal status as a late, out-of-order delivery and only fills metadata ("Reactivation comes exclusively from explicit status transitions (task.updated / progress status)"). A following task.progress without an explicit status does not reopen a terminal agent either (the !isTerminalSubagentStatus(agent.status) guard). So the second run never shows as running, and a failed run keeps its error, because the error is cleared only in applyStatus on the terminal → running transition.

Possible fix

Record the toolUseId of the start that opened the current run (the agent state does not keep it today). A task.started whose toolUseId differs from the recorded one is a new run, not a late copy of the first start: apply the terminal → running transition for it (applyStatus(agent, "running", at)), which also clears the previous run's error. A late duplicate of the original start carries the same toolUseId and would still be ignored, which keeps the protection that the current comment describes.

Impact

Minor bug or occasional failure

Version or commit

main @ de251fc (code checked); installed 0.0.43-nightly.20260926.2282

Environment

Desktop app on Linux (NixOS, Wayland, niri); Claude Code 2.1.283, Opus 5.5

Logs or stack traces

# Claude Code 2.1.283, `claude -p --output-format stream-json`: a subagent resumed with SendMessage
task_started      task_id=a85…  tool_use_id=toolu_…RhTc   (Agent call)
task_updated      task_id=a85…  patch.status=completed
task_notification task_id=a85…  status=completed
task_started      task_id=a85…  tool_use_id=toolu_…Qe1d   (SendMessage call)
task_updated      task_id=a85…  patch.status=completed
task_notification task_id=a85…  status=completed

# The failure case, from the thread's activities in T3 (times UTC)
09:26:33  task.started   taskId=aeb…  toolUseId=toolu_…mH9mHu   (Agent call)
10:11:20  task.updated   taskId=aeb…  status=failed  error="Agent terminated early due to an API error: You've hit your session limit …"
10:11:20  task.completed taskId=aeb…  status=failed
11:42:46  task.started   taskId=aeb…  toolUseId=toolu_…SoG957   (SendMessage call)
13:12:56  task.progress  taskId=aeb…  lastToolName=Bash  (no status)

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Confirmed on main at de251fc. The panel behavior matches the stream you captured.

ClaudeAdapter forwards each task_started as task.started with that call’s toolUseId and no status. In foldSubagentActivities (packages/client-runtime/src/state/subagentRuntime.ts), a task.started that arrives after a terminal status only fills metadata. It becomes running only when activationCount === 0 and the status is non-terminal, or when the status is idle. A later task.progress with no explicit status does not call applyStatus once the agent is terminal. applyStatus clears error, result, and completedAt only on a terminal → running transition, so a session-limit failure stays red for the whole resume, and activationCount stays 1.

The duration is startedAt → completedAt. Both stay pinned to the first run: settled rows in AgentsPanel freeze at completedAt, and a second terminal task.updated / task.completed is first-write-wins. Usage still max-merges, so the token count can climb on a row that looks finished.

The sidebar pill is a different path. ThreadBackgroundLiveness treats a task.started as live again, so the thread can read Working while the panel row stays completed or failed.

#5529 describes the same symptom and was closed on 2026-08-10 as fixed by #5569. That PR kept row height stable and split usage snapshots off the progress row. The start-after-terminal guard is unchanged since #5219, so this did not regress after a fix; the earlier report was closed against the wrong change. This issue is the live one.

#9408 tried to fix it by stamping status: "running" in the adapter when a settled task is re-registered under a different tool use. It was closed unmerged on 2026-09-19 because provider and orchestration changes are on hold for the V2 rewrite (#2829, still open). The panel does not use a v2 projection yet: ChatView still calls foldSubagentActivities with no v2Projection. Desktop wraps that web UI. Mobile does not render this panel.

A fold-only change stays on the path users actually hit and does not need an adapter or contract change. toolUseId is already on the persisted task.started payload. During the fold, remember every toolUseId already applied to that task. A start whose id is new is a new run: applyStatus(agent, "running", at) clears the previous error, result, and completedAt and bumps the run count. A start whose id was already applied is the late duplicate the current comment is protecting against. Remembering the set, rather than only the latest id, matters because a replay of an earlier run’s start can be appended after a newer run. A start with no toolUseId stays metadata-only, which keeps Codex children and workflow members on the existing path and keeps the late-start tests valid.

Impact stays as filed. The agent does run, and the events are stored. Only the panel status, error, run count, and duration are stale.