[Bug]: After Settle stops a thread's background server, the thread still shows "Waiting" with a Stop button

[Vantrongs]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. In a Claude thread, have the agent start a server as a background task (python3 -m http.server 8765 with run_in_background) and end its turn. The composer shows the Waiting strip with a Stop button.
2. Settle the thread.
3. Check the server's port and look at the thread.

Expected behavior

Settle stops the server, and the thread no longer shows the Waiting strip or the Stop button.

Actual behavior

Settle does stop the server: about two seconds after thread.settle the provider log shows query.close, and the server's whole process chain is gone. But the Waiting strip and its Stop button stay. Pressing Stop afterwards closes nothing, since no provider process is left, and only then does the strip go away.

Settle reaches the adapter through provider-session.detach, which closes the session scope, and closeSession only closes the query. The step that clears the thread's background work, thread.background-work.settle, is dispatched only after an interrupt (EffectWorker.ts), that is, only on Stop. So the thread keeps showing work no process will report on, which the settle comment says must not keep running after Settle.

A possible fix is to dispatch the same thread.background-work.settle after the detach that Settle and archive trigger.

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

No response

Workaround

No response

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @Vantrongs for the precise repro and for pointing straight at the missing thread.background-work.settle step.

Confirmed on current main (ce90eec). Settle stops the background server as intended. The bug is the Waiting strip that stays up afterwards.

thread.settle is allowed once the run is idle, and background work doesn't count as active. Settle then detaches the live provider session, just like archive does. For Claude, closeSession only calls query.close, which matches the provider log and the server process going away. Nothing on that path clears the provider-thread background roster or marks leftover background items as interrupted, and thread.settled only updates the thread record.

The Waiting strip comes from derivePendingBackgroundWork, which reads the background roster plus any still-active command, subagent, and dynamic-tool items. Those stay until thread.background-work.settle runs, and that only happens after provider-turn.interrupt, which is Stop. That's why the extra Stop clears the strip even though there's no process left to kill.

This isn't the Stop gap fixed in #13792 and #14636, which are both merged. Settle just never runs the same follow-up. Inactivity auto-settle goes through thread.settle too, so it has the same gap, and archive uses the same detach.

Likely fix area

Dispatching thread.background-work.settle after the settle and archive detach, as you suggested, lines up with the code. There are two details to watch:

• It has to run after the session is released. settleBackgroundWork leaves the roster in place while a live session still exists, because a live process is expected to report the clear itself.
• The command has to name a provider thread and turn that still resolve to a run. Otherwise dispatchBackgroundWorkSettle quietly does nothing.

A maintainer will decide on the fix direction.