Should background commands keep a thread in the Working section?

[BeLazy167]

With the Working section beta on, a thread leaves Working as soon as its turn ends if the only thing left running is a background command. The composer still shows "Running: ..." with a Stop button, but the sidebar treats the thread as done.

That's right for a dev server the agent started and walked away from, and it's why #14872 stopped commands from holding completion. But agents also use background commands to wait. With Claude, a background Bash re-invokes the agent when it exits. I had a thread start one to wait out a lockout and then rerun QA. It dropped into my inbox right away, though nothing needed me yet.

The server can't tell those two cases apart. So the question is what the Working section should optimize for:

1. Keep [Bug]: Sidebar hides a finished thread's unseen completion while a background shell it left running is still alive #14872 for the Working section. Commands don't count. A thread waiting on a command looks done.
2. Count any live background work, but only for section placement. Notifications, idle parking, and auto-settle stay on [Bug]: Sidebar hides a finished thread's unseen completion while a background shell it left running is still alive #14872. A dev server keeps its thread in Working until you stop it, and the thread jumps back to the top of the inbox when the command ends.
3. Something narrower, such as counting commands only for providers whose harness wakes the agent on exit.

Here is a live Claude thread that started sleep 1800 in the background and ended its turn, with the Working section beta on:

Today (main)	Option 2 (PR)

PR #15413 implements option 2 as one change in isThreadWorking, with before/after screenshots. I'm happy to switch to another option or close it if you'd rather keep the current behavior.

[coygeek]

Another real case for this, on nightly 0.0.46-nightly.20261005.2667: a Claude thread ended its turn saying it would commit and push once a background test suite finished. It went straight to the top of the inbox while the suite kept running. The server's projection had the thread at idle with pendingBackgroundTasks: [{ kind: "command", description: "Run live behavior suite …" }], all runs completed, and the suite's process still alive minutes later.

One detail that may help decide between the options: for Claude, the server already knows a background command will wake the agent. It just doesn't pass that on.

• The adapter maps every Claude local_bash task to kind: "command" (ClaudeAdapterV2.ts#L1720-L1723). It also tracks those tasks as able to wake the agent and starts a continuation run when one ends (#L3014-L3040). The claude_background_task_wake fixture asserts both: the wake run, and a roster entry of kind: "command".
• backgroundWorkHoldsCompletion says subagents and monitors hold the thread "because they wake the agent", while commands don't (orchestrationV2PendingBackgroundWork.ts#L62-L85). For Claude, that premise doesn't separate the two: its background commands wake the agent too.

So option 3 (count commands for providers that wake on exit) works out the same as option 2 for Claude. A dev server started with run_in_background also wakes Claude when it exits. Whether the agent wakes can't be the dividing line. Whether the agent means to resume isn't recorded anywhere today, short of an explicit wait marker like #14072.

Since that leaves no clean server-side signal, I'd lean toward option 2 (#15413): count any live background work for Working-section placement only, keeping notifications and auto-settle on #14872. The cost is that a dev server keeps its thread in Working until it's stopped, which the composer's Stop button already makes one click.

[saphid]

A fourth option, with a working demo in #16213: one Working section, more specific row statuses.

The case for a separate Waiting state is real. An agent generating code and an agent parked until a 40-minute benchmark finishes are different, and showing both as "Working" with a climbing timer hides that. "Waiting on tests" sets a clearer expectation.

But I don't think waiting should decide which section a thread is in:

• The section answers "is my task still underway?" Unfinished tasks belong in Working, whether the main agent, subagents, or a terminal is doing the work.
• The row answers "what's happening?" It can say "Working" (with its timer), or "Waiting on 2 subagents" / "Waiting on tests" with an agent or terminal icon.
• A dev server left running after the task is done should not keep it in Working.

#16213 does the row half without changing placement. A waiting row now names what will wake the agent, using the composer strip's wording and the existing backgroundWorkHoldsCompletion rule, so a dev server is never named and still doesn't hold the thread. Today the row says a bare "Waiting" on web and nothing at all on mobile.

Web: before / after

Mobile: before / after

For commands, the hard part is still the one this discussion is about: telling "waiting on tests" apart from "left a dev server running". With an explicit hold signal like #15315, a held command lands in Working and its row reads "Waiting on " with a terminal icon, through the same predicate and with no further UI change. Without that signal, I'd keep commands out of Working (option 1) rather than pin dev servers there (option 2).

[pascalandy]

Another case. Server 0.0.46-nightly.20261006.2735 (Linux), macOS desktop 0.0.46-nightly.20261009.2886, Claude Opus 5.5 thread, Working section beta on.

The agent started a headless Codex review as a background Bash command (run_in_background) and ended its turn with "La 2e ronde de Codex tourne. J'attends sa notification." ("Codex round 2 is running. I'm waiting for its notification."). The composer showed Running: Run Codex round-2 review of the pushed fixes with a Stop button. The thread row went to the top of the inbox showing only 1m, with no Working or Waiting label. Another thread was correctly in Working.

The red marks are mine: that row should have been in Working.

I'd back option 2 (#15413). What I ask the sidebar is "does anything here need me?", and the answer was no. Option 2's cost is a dev server keeping its thread in Working, which is easy to see and one click on Stop. Today's cost is hidden: I open a thread that looks done, find the agent still waiting, and have to remember to come back.

A per-task wait flag (as in #15315) would be cleaner long term. #15413 fixes placement now without touching alerts or auto-settle.

[syamilj]

Another case on desktop 0.0.46-nightly.20261013.3053 (macOS), Claude Opus 5.5 thread, Working section beta on.

The agent fanned out 8 threads, then started a background Bash command (run_in_background) that waits until all 8 have logged their results, and ended its turn listing what it will do once they finish (similarity check, revisions, PR + merge, report back). The composer shows Running: Wait in background until all 8 log v2 cost rows with a Stop button. t3_thread_list reports the thread as completed, so its row sits at the top of the inbox while Working (10) holds the very threads it is orchestrating.

Nothing in that thread needs me. The orchestrator pattern (launch threads, wait on them with a background command) makes the "looks done but isn't" row especially misleading: the parent looks finished while its children are visibly still working.

+1 for option 2 (#15413).

[BeLazy167]

#15413 was closed under the prior-approval rule, so here is the decision I'm asking for.

Four reports above show agents waiting on their own background commands while their threads land in the inbox. Three of the four commenters (@coygeek, @pascalandy, @syamilj) back option 2. @saphid prefers option 1 until an explicit wait signal exists.

A wake-on-exit flag can't separate the cases, because Claude also wakes when a dev server exits (see @coygeek). The real choices are:

1. Keep commands out of Working (status quo).
2. Count live background commands for Working placement only (fix(client-runtime): background commands keep threads in Working #15413). A dev server stays in Working until you stop it. Notifications and auto-settle don't change.
3. Add an explicit wait signal, as in feat: Wait keeps a thread working until its background command ends #15315, which closed without merging.

@juliusmarminge @t3dotgg, which direction would you approve? I'll update or reopen a PR to match.

[BeLazy167]

@coygeek @pascalandy @syamilj, thanks for the reports. If option 2 still matches what you need, an upvote on the discussion helps show maintainers how many people hit this.

[PiquelChips]

Another option for an explicit wait signal: let the agent declare the wait, not the user.

The agent is the only party that knows whether it is waiting on a command or leaving it running. Claude already returns the task ID T3 tracks on the roster ("Command running in background with ID: bdqirlcyw", the same task_id as task_started). So T3 could expose one small MCP tool, e.g. t3_background_wait({ taskId }), that the agent calls after starting a background command it intends to wait on. Until that command exits, it holds the thread like a subagent does: the thread stays in Working, there's no completion alert or push, and auto-settle doesn't settle it.

• The default doesn't change. Unmarked commands keep the fix(clients): a thread left running a dev server alerts as completed #14213 / fix(web): a thread that left a shell running shows its unseen completion #14910 behavior, so a dev server never holds a thread.
• Forgetting is cheap. If the agent doesn't call the tool, you get today's behavior (a false alert), not a dev server stuck in Working for hours. That's why I'd make it opt-in "wait" rather than opt-out "detach".
• The tool's description is the instruction. Something like "background commands are treated as left running; call this if you will wait for this one". No system-prompt changes needed.
• Difference from feat: Wait keeps a thread working until its background command ends #15315: that PR asked the user to click Wait. Here the agent declares its own intent, so nobody has to babysit the thread.

Per provider: Claude works as described. Codex and Grok need a check that the ID the agent sees matches the roster entry; where it doesn't, the tool would report "not supported" rather than guess.

@juliusmarminge @t3dotgg, would you approve this direction? If so, I'm happy to open a PR.

Note

Written by Claude Opus 5.5 in Claude Code (via T3 Code)

[BeLazy167]

@PiquelChips, a correction: #15315 already had this. Besides the Wait button, it added a wait_for_background_commands MCP tool so the agent could hold a command it started. Its verification shows Claude calling the tool and the thread reading "Waiting". It closed on Oct 5 without merging, and the thread doesn't say why. That close reason is the open question for an agent-declared wait.

An opt-in tool also misses the cases reported here. None of the four agents above was told to mark its command. Each one started a background Bash command and said in its own words that it was waiting. With an opt-in tool, all four would still land in the inbox until agents learn to call it.

Option 2 (#15413) fixes placement for those cases today and doesn't touch alerts or auto-settle. An explicit wait signal can still come later. If one lands, Working placement can switch to it.

@juliusmarminge @t3dotgg, the decision I asked for above still stands: option 2 now, or wait for an explicit signal?

[jlipworth]

Another case, desktop on macOS, Claude thread. The agent pushed a fix, started a run_in_background command ("Wait for CI and Argo on layout fix"), and ended its turn. The composer shows Running: Wait for CI and Argo on layout fix · Stop. In the sidebar, the thread looks like any finished thread with nothing to show it's waiting.

From the sidebar, I need to tell "waiting on something, don't look yet" apart from "done, ready for me." Right now a thread waiting on CI looks the same as a finished one, so I open it, find nothing to do, and have to remember to come back later.

I'd rather see an occasional dev server show "Waiting" than have threads that are really waiting look finished. An agent-declared wait, as suggested above, would cover both cases. Until that exists, Claude commands that wake the agent when they exit should count as waiting.