Repository navigation
Show a Waiting status while a thread has running background tasks #19926
Description
Problem
A Claude agent can start a long-running shell command with run_in_background (for example, full local CI) and then end its turn. T3 then marks the thread Completed (status: completed, activeRunId: null), even though the composer still shows Running: Run full local CI on batch branch · Stop. When the command exits, the agent wakes up and starts a new run.
In the sidebar, the thread looks finished or stale while work is still happening. From the list, you can't tell whether the thread is idle or waiting on CI.
Proposal
- Add a Waiting thread state, used when no run is active but at least one background task (shell command, monitor, background subagent) is still running.
- In the sidebar, show it as a subtle in-progress indicator, with the task label on hover, e.g.
Waiting · Run full local CI. - Switch back to Working when the agent wakes up, and fall back to Completed when every task has finished or been stopped.
- Expose the same information through the thread API (e.g. a
backgroundTaskslist orwaitingOnfield ont3_thread_read/t3_thread_list), so orchestrating agents can tell the difference too.
Related
#16611, #16610, #17767: the same root problem (completed vs. still working) for subagents and /goal.
Reacted by Lucas, Jonathan Lipworth, BlackPhoenixSlo, Andrei Shenets, iboxgithub, SKC, Ashkaan and Ben Sandison
Activity
iboxgithub commentedon Oct 18, 2026
same problem here
Birzool commentedon Oct 19, 2026
Adding a use case for this issue, since it pulls the other way from #14872 / #14910.
Our agents start long jobs with
run_in_background: a full local CI run, a build, a test suite. The agent ends its turn and wakes up when the command exits. While the command runs, the sidebar row and the command palette pill read Completed / Done, but the composer still showsRunning: … · Stop. From the thread list we cannot tell a finished thread from one still waiting on its own CI.In our local build we treat a non-empty background roster as Waiting again (the pre-#14910 rule in
shellRuntimeandresolveThreadStatusPill). We kept the completion alert firing, so notifications do not regress. That brings back the #14872 case: a thread that left a dev server running reads Waiting for as long as the server lives.So the core problem seems to be that the roster's
kind: "command"cannot tell "a command the agent will wait for" from "a command left running". A marker of that kind on the roster entry would let both #14872 and this issue work. Leaving the direction to maintainers.SKCarlsson commentedon Oct 20, 2026
Real case from today (nightly, Claude Opus 5.5). Two threads in one project both ended their turn to wait on test suites:
Bashcommand plus aMonitoron its log. It shows Waiting.run_in_backgroundcommands: two e2e suites and a cache-warming loop. Its last message: "e2e:markets is running, with e2e:vercel:deploy queued after it. When both pass, I'll … merge." It shows Completed, and from the sidebar I couldn't tell it was still working.So today it depends on whether the agent happened to start a Monitor. #22055's
t3_background_waitwould fix this.One more thing would help: B's suites were stuck for 15+ minutes behind A's suite on a machine-wide test lock. "Waiting · e2e:markets" looks the same whether the job is running or blocked. Showing how long each job has been running, and the last line of its output on hover, would make that visible without opening the thread.
VDrozd-Cyclis commentedon Oct 20, 2026
Additional observed case on 0.1.1-nightly.20261020.3411, commit
d36b7da2485b, macOS arm64, Claude Opus 5.5.The thread briefly returned to the inbox as finished, then moved back to Working without user input. Read-only inspection of persisted events and replay of the installed build's pending-background-work functions explain the transition.
On 2026-10-20, all times UTC:
kind: "command"task waiting for PR validation to finish. There were no remaining active subagents. ReplayingderivePendingBackgroundWorkreturned that command, andbackgroundWorkHoldsCompletionreturned false.The agent had explicitly said it was waiting for the final CI job before finishing its deliverable, so this command was awaited work.
This matches the installed kind-based hold rule: commands return false, while subagents, monitors and background tasks return true. The status pill uses that same helper.
For comparison, replaying the earlier parent completions at 13:14:14.173 (two active delegates) and 13:18:13.403 (one active delegate) returned true. This particular gap therefore supports the awaited-command case in this issue and #22055; it does not establish a separate premature-completion bug for active subagents.
Verification limits: the brief visual transition was user-observed, without a screen recording. The timestamps, roster and automatic wake were verified from durable events; the hold rule was executed from the installed bundle. No application state was modified and no fresh minimal reproduction was run.
tiliakoos commentedon Oct 20, 2026
Additional evidence for the awaited-command case, from a Claude Opus 5.5 PR workflow on macOS today (2026-10-20), waiting for checks on #22382.
Read-only inspection of the persisted event log gives this timeline (UTC):
Wait for CI and CodeRabbit on PR #22382, withkind: "command". Claude launched a background shell loop polling the PR checks.At the parent completion there were no active subagents, no active foreground run, and no registered PR watch. The remaining work was the CI-wait command. That leaves roughly eleven minutes where the agent still owed a follow-up but its run was completed.
Executing the current checkout's
derivePendingBackgroundWork/backgroundWorkHoldsCompletionhelpers with the recorded roster retains the task but returnsfalsefor holding completion because its kind iscommand. This supports this issue and the awaited-command distinction in #22055; it does not establish a separate bug involving still-running subagents.Verification limits: the Done badge was user-observed without a recording, and this is a matching historical case rather than a fresh minimal reproduction. The timeline and roster were verified from durable events; the helper check used the current source checkout, not the installed bundle. No application state was modified.
bensandison commentedon Oct 21, 2026
+1 on this.
I'm really liking the new working threads section, but Claude threads show in the Ready section while they are waiting on a background script. IMO it would make more sense to add 'waiting' threads to the 'working' section.