Repository navigation
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- In a Claude thread, have the agent start a dev server in the background (for example
python3 -m http.server) and end its turn. - Wait for the completion alert, then look at the thread's row in the sidebar.
Expected behavior
The row agrees with the alert: "Completed" until I open the thread, then its normal state.
Actual behavior
The "Thread completed" toast appears, and the iOS Live Activity says "Agent work completed" with the thread marked "Done". The desktop row disagrees: it stays in the sidebar's "Working" group and says "Waiting" for as long as the server runs, sometimes for hours, and the unseen "Completed" pill never appears. Nothing in the row shows the server or its port. The pendingBackgroundTasks check in Sidebar.logic.ts returns "Waiting" before hasUnseenCompletion is reached. The mobile thread list shows waiting the same way.
When the server exits, its task notification wakes the agent, and the row switches to "Working" with minutes already on the timer. A wake run keeps the work start of the run before it (wakeWorkStartedAt: a wake "carries on the work of the run that started last"), so the timer counts from the prompt of the turn that had already completed, including the whole time the server ran. That fits a wake after held work, a monitor or a subagent, but here the alert had already reported that work as finished.
#14213 fixed the alert for this case (#13965): it fires when the only pending work is a command, per backgroundWorkHoldsCompletion. It notes: "The sidebar and the mobile list still show Waiting while a dev server runs. This PR only changes when the alert fires." So "Waiting" now covers two states the row can't tell apart: the agent will continue because a monitor or a subagent will wake it, or the agent is done and left a server running.
A possible fix is to let the row use the same backgroundWorkHoldsCompletion rule: with only commands left, show "Completed" while unseen and the normal state after it, perhaps with a · 1 running suffix, and start a new timer when such a command wakes the agent. Listing the ports there would need the agent's own listeners, which port discovery doesn't track today (#9832).
Impact
Minor bug or occasional failure
Version or commit
0.0.46-nightly.20261003.2623 (fed41fa)
Environment
Desktop app on Linux (NixOS, Wayland, niri); Claude Code 2.1.288
Logs or stack traces
No response
Screenshots, recordings, or supporting files
In-app toast after the turn: "Thread completed"
The same thread's row at that time: "Working" group, "Waiting"
iOS Live Activity at the same time: "Agent work completed", thread "Done"
Workaround
No response
Activity
juliusmarminge commentedon Oct 3, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks @Vantrongs for the write-up and the side-by-side screenshots. They made the mismatch easy to see.
The sidebar and mobile-list part is already fixed on main. It's the same bug as #14872.
Your build is nightly
0.0.46-nightly.20261003.2623(fed41fa). On that commit, any leftover background task parks the thread atidle, and the row label treats a non-empty roster as "Waiting" before it checks for an unseen completion (models.ts, Sidebar.logic.ts). That's why the toast and the iOS Live Activity said done while the row stayed in Working. Alerts already ignored command-only work after #14213, but the row and the list didn't.These changes landed after
fed41fa:backgroundWorkHoldsCompletionis true. A dev server (kind: "command") now shows the run's own status, so the unseen "Completed" appears and the row leaves the Working group. Subagents and monitors still show "Waiting". The mobile list uses the same status.Nightly
0.0.46-nightly.20261003.2632already includes #14910 and #15114, so updating to that or anything newer should fix the row. Listing the server's port is still separate (#9832).The timer is a separate behavior. When the command exits, Claude's task notification starts a wake, and a wake keeps the previous run's work start (Orchestrator.ts). That's intended for monitor and subagent wakes, but it's a worse fit for a command whose turn already reported as completed. Resetting the clock only for commands would be its own change, so if that still bothers you after updating, please open a separate issue.
I've marked this as a duplicate of #14872.
Vantrongs commentedon Oct 3, 2026
Thanks, confirmed. #14910 covers this case: Claude's background Bash is a
command, so it no longer holds the row or the mobile list in Waiting. My build (fed41fa) predates it, and I missed #14872 because I only searched open issues. Closing as a duplicate of #14872.I'll check the timer after updating and open a separate issue if it still counts from the earlier prompt.