[Bug]: Stop does nothing on a "Running" banner for a command the server already finished #18188

What happened

A Claude thread shows "Running: python3 -m venv … && pip install -q pyarrow … python -c …" above the composer with a Stop button. The command was an ordinary Bash call that took 4 seconds and finished normally about nine hours ago. Nothing is running on the machine. Pressing Stop (several times) does nothing and the banner stays.

Diagnosis

The server and the banner disagree about this command, and Stop cannot reconcile them.

1. Server state says finished. In the state database the command's turn item has status completed (startedAt 01:33:03.699Z, completedAt 01:33:07.826Z). The provider thread's pendingBackgroundTasks is []. The thread has no command_execution, dynamic_tool or subagent item in a non-terminal state, and ps shows no matching process. The Claude transcript holds the tool result 4 seconds after the call.
2. The banner comes from the client's copy of the thread. ChatView calls derivePendingBackgroundWork on serverProjection.turnItems, so the client still holds this item as running. The item sits far outside the bounded snapshot: 1,398 of the thread's 1,783 turn items are newer.
3. Stop does nothing. interruptThreadTurn re-fetches getThreadProjection (bounded, 75 items), runs derivePendingBackgroundWork, finds nothing, and returns { sequence: 0 } without dispatching run.interrupt. In the server trace, 11 getThreadProjection requests for this thread land within 04:24:08–04:24:11 MDT, which matches when Stop was pressed. The only commands dispatched for the thread are thread.visit, message.dispatch and pull-request link/sync; there is no run.interrupt. By the code, no error is raised in this case, so the button just returns to "Stop".
4. Why the client copy stayed running is not determined. orchestration_v2_events has 0 rows for this thread, so a missed completion cannot be replayed from it.

Relation to open reports. #16586 is the same silent no-op in Stop, but there the command really was running. Its proposed fix (find active commands in the full projection, or pin them into the snapshot) would not help here: the server item is completed, so there is nothing to find, and nothing sends the client a correction. #15993 and #16749 cover items stuck running on the server, and #18163 covers a provider roster that is not cleared; neither applies, because the server state here is already clean.

Steps to reproduce

Not reduced to a deterministic repro. What was observed: a Claude thread with 69 runs and 1,783 turn items, one ordinary Bash call that ran for 4 seconds in an early run, and a Running banner for it that never cleared. Not yet tested: whether reloading the app clears the banner, and whether a fresh client shows it.

Version

t3 v0.0.46-nightly.20261011.2955 (server); code read at main 1f6df6b

Environment

Linux 7.2.9 (WSL2, x86_64); T3 Code server nightly as above (client app version not recorded); claudeAgent, claude-sonnet-5-5

Evidence

item status in state db: completed, completedAt 2026-10-11T01:33:07.826Z
provider thread pendingBackgroundTasks: []
non-terminal command/tool/subagent items in thread: 0
turn items newer than this one: 1398 of 1783
trace 04:24:08-04:24:11: 11 x ws.rpc.orchestration.getThreadProjection, 0 x run.interrupt
thread command types in trace: thread.visit, message.dispatch, thread.pull-request-link.sync, thread.pull-request.link
orchestration_v2_events rows for thread: 0

Related issues

#16586 (same silent no-op, but the command was really running), #15993, #16749, #18163. Not a duplicate: here the server already says completed, so fixing how Stop finds running work would leave this banner in place.

Fix applied or workaround

None found. Stop does not clear it. Not tried: reloading the app.

Filed by

claude (claude-sonnet-5-5) in Claude Code, run inside T3 Code