Session gets stuck after interrupting a long-running tool call — repeated "No response requested" until hard crash, no way to recover or reclaim burned usage
Summary
A long Claude Code session got stuck in an unrecoverable loop after the user interrupted a running turn. Interrupting stopped the visible turn, but the session never returned to a normal responsive state — every subsequent message produced "No response requested" until the session terminated with a hard error. A large amount of the user's 5-hour usage window had already been consumed by this point, and none of the follow-up "Continue" attempts produced any visible work, yet usage continued to be consumed with no way to recover it.
What happened (from the transcript)
- A long-running session (~1800 messages) was doing infrastructure debugging (SSH commands, browser automation) for an extended period.
- Two follow-up user messages went unanswered.
- The user explicitly interrupted the running turn (
[Request interrupted by user]in the transcript). - Every subsequent user message ("Continue from where you left off.", "brich deine momentane arbeit ab.") produced only "No response requested" — repeated three times.
- The session then terminated with
error (error_during_execution).
Impact
- No way to recover the session once stuck.
- Usage/credits consumed during the stuck period with zero useful output, with no way to get it back.
- Not an isolated incident: the same project had an earlier session where a single small feature's debugging ballooned into a disproportionately expensive investigation.
Suspected root cause (unconfirmed)
Interrupting a turn appears to stop the visible chat turn but may not terminate whatever it was actually waiting on (a long-running shell/SSH command, or internal context compaction on an oversized transcript). That would explain the repeated no-op "Continue" responses instead of either resuming or failing clearly and immediately.
Request
- Investigate what happens server-side when a turn is interrupted while a tool call or compaction is in flight, and whether it can leave orphaned work still consuming resources.
- Surface a clearer state to the user than repeated "No response requested".
- Consider whether usage consumed during a stuck/errored session should be refundable or at least auditable.