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