Queued Claude workflow members display as running with a 'Thinking' placeholder#25307
What happened
While a Claude workflow was running, one of its member subagents (critic:mfg-supply) showed "Working for 35m41s" with a single "Thinking" row and no messages or tool calls. It looked hung. In fact it had not started yet: it was waiting for a concurrency slot behind other members. It started 39 minutes after the workflow launched, and its tool calls then appeared normally.
Diagnosis
Claude Code (2.1.309) reports a member that is waiting for a concurrency slot as state: "start" with queuedAt set and no startedAt. When the member actually begins, the CLI sends startedAt, and later frames switch to state: "progress". The CLI never sent state: "queued": across all of this machine's provider logs, there are 1,418 start entries, 1,405 of them without startedAt, and zero queued.
apps/server/src/orchestration-v2/Adapters/claudeWorkflowProgress.ts maps start → running (AGENT_STATES) and decides state from the string alone. A queued member is therefore projected as running. Then, in projectClaudeWorkflowMembers (ClaudeAdapterV2.ts), startedAt falls back to now when the status is running and the snapshot has no startedAt. The member's thread gets a running timer that starts when the workflow launches, plus a "Thinking" placeholder, even though no agent exists yet. In the same snapshot, members of a later phase (verify:*, phase 2) were also start, so every not-yet-started member of the run renders as working.
Suggested fix: treat state: "start" with no startedAt as queued, and only use running once startedAt is present (or the state is progress). progress currently reaches running only through the unknown-state fallback, so it could be mapped explicitly too. main still has the same mapping.
Steps to reproduce
- In T3 Code, start a Claude thread and run a workflow with more agents than its concurrency limit, for example a phase with 6+ long-running agents, or two phases.
- Open a member that hasn't been scheduled yet, from the workflow view or the lineage list.
- It shows "Working for Xm" counting from the workflow's launch, with a "Thinking" row and no activity, until it actually starts.
Version
0.1.3-nightly.20261023.3553 (server on the remote host; the triage CLI was 0.1.2)
Environment
Server: Ubuntu 26.04.1 (x86_64), t3 service (systemd user unit), Claude Code 2.1.309, model claude-opus-5-5. Client: T3 Code desktop app on macOS 26.5 (arm64), connected to the remote server.
Evidence
| 1 | # Workflow task wt8pak7dl launched 03:41:08Z. Snapshot entry for the member, 112 consecutive frames from 03:41:08Z to 04:19:29Z: |
| 2 | {"type":"workflow_agent","index":5,"label":"critic:mfg-supply","phaseIndex":1,"phaseTitle":"Critique","state":"start","queuedAt":1792986068193,...} # no startedAt |
| 3 | # Same frame, other members: |
| 4 | critic:video-path done | critic:usb-topology done | critic:power-thermal-mech progress | critic:safety-software progress |
| 5 | critic:mfg-supply start | verify:video-path start | verify:usb-topology start # phase 2 members, also "start" |
| 6 | # 04:20:30Z, first frame with startedAt (2362 s after queuedAt): |
| 7 | {"...","label":"critic:mfg-supply","state":"start","startedAt":1792988430207,"queuedAt":1792986068193,...} |
| 8 | # 04:20:42Z onward: |
| 9 | {"...","label":"critic:mfg-supply","state":"progress","startedAt":1792988430207,"toolCalls":6,...} |
| 10 | # UI at 04:16:50Z: "Working for 35m41s" (= launch at 03:41:08Z + 35m41s), single "Thinking" row. |
Related issues
#15448 (closed): Orchestrator V2 shows a Claude workflow as a plain subagent. That was about workflow parsing being dropped entirely; this is about the queued state within a parsed workflow. No existing issue found for queued members showing as running.
Fix applied or workaround
None needed. The member started on its own. Users can tell queued members from hung ones only by checking the provider event log.
Filed by
Claude Code (claude-opus-5-5) via t3 triage