fix(server): stop actually stops a runaway Claude turn

[xiaogwu]

The problem

Clicking Stop during a Claude turn could freeze every thread in the app for close to two minutes, and then not stop the agent at all.

Two defects combine:

1. ClaudeAdapter.interruptTurn awaited context.query.interrupt() with no time bound. The Claude Agent SDK's interrupt is a control request that can block until the in-flight tool call returns. Measured twice on 2026-08-17 against claudeAgent: 114s and 111.5s.
2. ProviderCommandReactor drains every thread command through a single DrainableWorker lane. One hung provider call therefore blocks all threads, on every client. Later Stop clicks were persisted to orchestration_events and never processed.

An acknowledged interrupt is also not proof the turn ended. The event log shows the agent kept working straight through the stall: a burst of identically-timestamped tool calls flushed the instant the queue cleared.

The fix

Stop now escalates instead of trusting the provider.

interruptTurn arms a detached watchdog, then asks the SDK to interrupt with a 5 second bound on the ack. If the same turn is still live 5 seconds later, the session is torn down through the existing stopSessionInternal. That path routes through completeTurn, which updates the resume cursor, so a forced teardown still leaves the thread resumable and the UI honest about the turn being interrupted.

Turn identity (context.turnState?.turnId compared against the id captured at interrupt time) is what distinguishes "same turn still live" from "turn ended" and "a new turn started". No new signal or Deferred was needed.

The watchdog runs on a make-level Effect.runForkWith capture, so under test it inherits TestClock and the escalation is deterministic rather than timing-dependent.

Deliberate non-change

The reactor's queue stays serial. Forking the interrupt off the shared lane would let a following turn-start-requested race ahead of a session teardown and prompt into a dying session. Bounding the adapter call shrinks the global block from ~112s to ~5s, which is the win without the race.

Scope

Only the Claude adapter changes. It is the only provider with observed hangs. Codex, Cursor, Grok, Gemini and OpenCode are not audited yet.

No client change is needed. Web, desktop and mobile all send the same thread.turn.interrupt request through packages/client-runtime/src/operations/commands.ts, so all three surfaces are fixed by the server change alone.

Verification

• vp test run apps/server/src/provider/Layers/ClaudeAdapter.test.ts — 72 passed, including two new tests.
• Negative check: with the fix reverted, the new never-acknowledged-interrupt test hangs to the 60s harness timeout. That is the bug reproducing.
• tsgo --noEmit on apps/server — 0 errors.
• vp lint on both files — clean (one no-useless-spread warning, pre-existing on main).
• Not verified at runtime in a real client.

Upstream

Upstream knows about this bug and has not shipped a fix. Open issues #4524 and #4713 describe it. Open PR #5891 fixes it by always closing the session and never calling interrupt() at all, which discards the session even on a Stop that would have worked. This fork keeps the graceful path and escalates only when the agent ignores it. If pingdotgg#5891 merges, expect a conflict in these two files.

Written by Claude Opus 5 in T3 Code.