Show a Waiting status while a thread has running background tasks

[brahimhamichan]

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 backgroundTasks list or waitingOn field on t3_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.

[iboxgithub]

same problem here

[Birzool]

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 shows Running: … · 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 shellRuntime and resolveThreadStatusPill). 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]

Real case from today (nightly, Claude Opus 5.5). Two threads in one project both ended their turn to wait on test suites:

• Thread A left a background Bash command plus a Monitor on its log. It shows Waiting.
• Thread B left only run_in_background commands: 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_wait would 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]

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:

• 13:19:02.772: the last delegated subagent completed.
• 13:23:37.154: parent run 66 completed. Its provider roster still contained one kind: "command" task waiting for PR validation to finish. There were no remaining active subagents. Replaying derivePendingBackgroundWork returned that command, and backgroundWorkHoldsCompletion returned false.
• 13:24:39.585: run 67 was requested automatically after the background command completed with exit code 0. Its input was the provider's background-command completion notification, explaining the return to Working roughly 62 seconds later.

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]

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):

• 15:46:11.287: the provider roster contained Wait for CI and CodeRabbit on PR #22382, with kind: "command". Claude launched a background shell loop polling the PR checks.
• 15:46:14.670: the parent run completed while that command remained pending. Claude's last message was: “Waiting on Test Web and CodeRabbit for fix(web): a refused review shows GitHub's reason #22382; I'll record the outcome in the vault when they finish.”
• 15:57:09.158: the command disappeared from the pending roster.
• 15:57:10.508: its completion notification automatically requested the next run; Claude resumed and recorded the final CI/review results.

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 / backgroundWorkHoldsCompletion helpers with the recorded roster retains the task but returns false for holding completion because its kind is command. 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]

+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.

[kaovilai]

Adding our use case: we regularly have threads whose whole job is babysitting a PR — watch checks, triage review bots, push fixes — and they end their turn with a background wait. With the Working section enabled in the sidebar, those threads drop into Ready/Completed and look identical to threads that are genuinely finished.

The angle the existing comments haven't covered: waiting threads are exactly the ones we want to prompt next. When the wait resolves (CI goes green, a reviewer replies), that thread is primed for a follow-up prompt, but there's no way to find "just waiting" from the list — you have to open each thread and look for the composer's Running: … · Stop strip. A Waiting state in the sidebar, and ideally a way to jump straight to waiting threads, would turn that into a one-glance decision instead of a thread-by-thread audit.

+1 on the awaited marker direction above. Our agents do reach for t3_background_wait / PR watches when they remember, but raw background shell waits (gh run watch, log polling loops) are just as common and still read as done.

Note

Written with Claude Code (model: rits/zai-org/glm-5-3) on behalf of the user.

[kaovilai]

Workaround we've settled on while waiting for this — sharing in case it helps others with the same pain:

Since a PR watch is an awaited task, whatever thread holds it sits in the Working section until merge/close. So instead of each PR-owning thread watching its own PR, we run one dispatcher thread that holds the watches for the whole fleet:

• Every PR-owning thread just links its PR and stays in the inbox. Linking already gets it polled by the sync reactor — no watch, no Working-section parking.
• The dispatcher watch_pull_requests every fleet PR. Because watch reads share the sync reactor's cached reads, this adds essentially zero extra GitHub requests over what linking already costs.
• Wakes land on the dispatcher (check fail/pass, new review/comment by someone else, conflicting branch). It resolves the owning thread for that PR — the linked-PR list is the ownership registry — and forwards the event with t3_thread_send.
• One slow background script (10-min cadence) in the dispatcher covers what wakes can't see: stuck required checks that never post a status (no change → no wake), and BEHIND-but-not-conflicting rebase drift.

Net effect: exactly one thread in Working (the dispatcher, deliberately labeled), every PR thread purely waiting in the inbox and woken only when its PR has news, and near-zero incremental API usage no matter how many PRs are watched.

It works, but it's a workaround shaped entirely around the missing Waiting state — the dispatcher thread is a stand-in for "these threads are waiting, not working." Would still very much like the real thing here: a Waiting distinction in the sidebar (and on the API surface) so this routing layer can be deleted.

Note

Written with Claude Code (model: rits/zai-org/glm-5-3) on behalf of the user.