Repository navigation
[Bug]: Stop gives no pending feedback, so repeat clicks turn into Resume and send "Continue where you left off" #20404
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
- Start a run, ideally on a thread that has delegated tasks, where Stop takes several seconds.
- Click Stop.
- Nothing changes, so click it again a few times.
Expected behavior
The click immediately changes the button to a disabled "Stopping…" state until the run actually settles, so it's clear the request was received. Clicks while it's stopping do nothing. After the run stops, the first click should not quietly resume it.
Actual behavior
The button looks the same until the provider confirms the interrupt. Once the run is interrupted, the same button acts as resume. The extra clicks then send "Continue where you left off" and start a new run, and I have to stop that one too. The timeline ends up with "Run interrupted by user", then the automatic "Continue where you left off", then "Run interrupted before provider start" (screenshot attached).
Related: #8618 (same "Stopping…" request, closed), #20342 (likely cause of the slow stop), #17184 (another path that sends "Continue where you left off" automatically)
Impact
Minor bug or occasional failure
Version or commit
0.1.1-nightly.20261016.3203
Environment
macOS 26.6.2, desktop app (Nightly), Claude provider
Logs or stack traces
Timeline from local server traces + statev2.sqlite (UTC, thread 1bb52ab2-…, Claude provider):
22:18:31.747 Stop click #1 → EnvironmentCommands.interruptThreadTurn (818 ms round-trip)
22:18:32.564 ClaudeAdapterV2.interruptTurn starts (1412 ms, Success)
22:18:34.371 run 119 → interrupted (~2.6 s after the click, no UI change meanwhile)
22:18:34.933 repeat click: user message "Continue where you left off." (creationSource: web) → run 120 starts
22:18:35.118 Stop click again → interruptThreadTurn (116 ms)
22:18:35.572 run 120 → interrupted ("Run interrupted before provider start")
Same pattern 15 min earlier in the same thread:
22:03:53.122 run 114 → interrupted
22:03:53.754 "Continue where you left off." → run 115
22:03:54.416 run 115 → interrupted
6 auto-sent "Continue where you left off." messages in my local state DB overall. No errors; every step succeeds, so there's no stack trace.Screenshots, recordings, or supporting files
Workaround
No response
Activity
juliusmarminge commentedon Oct 16, 2026
Note
Grok responding on behalf of Julius.
I can confirm this on main: the web composer has no pending-stop state.
ComposerPrimaryActions.tsx, the Stop button only disables on!canOperateThread. Clicking it callsonInterrupt()without awaiting it and sets no local "stopping" flag, so the button looks the same until the server reports the run as interrupted.canInterruptgoes false, the same slot renders the send button in "Resume thread" mode (showResume,onClick={onResume}). Clicks that were meant for Stop land on Resume, and Resume sends "Continue where you left off".This is separate from what makes the stop itself slow. That's tracked in #20342 (walking the delegated-task tree) and in the Claude interrupt PRs #16419 / #17498. Speeding those up shrinks the window but doesn't close it. #8618 asked for "Stopping…" feedback, but it was closed for a server-side stuck-state fix, not this UI gap. #17184 is a different automatic-continue path (cancelled
/compact).Possible directions:
Thanks for the timeline. The 0.6 s gap between the interrupt and the auto-sent message made this easy to pin down.
fix(web): Stop shows a pending state and repeat clicks no longer resume