Session auto-resume is a no-op: "Continue from where you left off." always answered with "No response requested." (17/17, 100% failure)

Summary

When a session is interrupted (app crash, disconnect, reload), Claude Code injects a synthetic user message reading exactly:

Continue from where you left off.

In 17 out of 17 occurrences across two months of my local transcripts, the assistant replied No response requested. and ended the turn. The session then sits dead — no error, no indicator, no retry — until I notice and manually type "Resume".

The auto-resume mechanism has a 100% failure rate in my logs. It has never once worked.

Reproduction

1. Be mid-workflow in a long Claude Code session (Desktop app, Windows).
2. The app crashes, or the session is otherwise interrupted.
3. On recovery, the app injects Continue from where you left off. as a user-role message.
4. The assistant responds No response requested. — stop_reason: "stop_sequence", zero tool calls, single sentence.
5. The session is now dead. Nothing further happens until a human intervenes.

This happened while I was investigating this very issue. The app crashed at ~16:05 today; the injection fired; the reply was No response requested.; the session stopped. I recovered it by typing "Resume" by hand.

Evidence

Extracted from local JSONL transcripts (~/.claude/projects/<project>/*.jsonl) — 89 session files, 64,046 records, spanning 2026-06-25 → 2026-08-24. Events deduplicated by record UUID (the same session can appear in more than one transcript file when git worktrees are used).

| | |
|---|---|
| Unique Continue from where you left off. injections | 17 |
| Replied No response requested. and stopped | 17 (100%) |
| Successfully continued | 0 (0%) |
| Distinct sessions affected | 13 |

Every failure carries stop_reason: "stop_sequence", zero tool calls, and a one-sentence body.

All 17, in order:

2026-06-27 14:28:18    2026-07-30 00:00:45    2026-08-14 21:18:33
2026-07-04 15:14:11    2026-07-30 13:10:04    2026-08-17 19:09:50
2026-07-05 19:46:08    2026-07-30 22:39:05    2026-08-18 00:27:41
2026-07-27 15:49:01    2026-08-01 00:55:01    2026-08-18 22:05:32
2026-07-29 00:33:36    2026-08-08 15:00:05    2026-08-21 18:28:10
                                              2026-08-24 16:05:44

Why this is costly

The injection exists so an interruption can be invisible — the session should pick up where it stopped. Instead the interruption becomes permanent and silent:

• Long multi-step workflows (research fan-outs, review pipelines, build sequences) die partway with no indication that anything went wrong.
• The failure is indistinguishable from the assistant having simply finished its turn. There is no error, no toast, no "resume failed" state.
• Recovery depends entirely on a human noticing that nothing is happening. Because the resume message is synthetic, a user who stepped away has no idea it was ever sent or that it failed.

Expected behaviour

Any one of:

1. The resume injection should actually resume — the assistant should continue the interrupted work rather than treating the prompt as requiring no reply.
2. If the assistant declines to continue, the client should detect it and surface it — a visible "couldn't resume this session" state instead of silence.
3. The injected prompt should be unambiguous that action is required. Continue from where you left off. is evidently being read as a no-op notification rather than an instruction, with perfect consistency.

Environment

• Claude Desktop, Windows 11 Pro (10.0.26200)
• Claude Code in the Desktop app
• Long multi-hour sessions, 1M context, heavy tool use, multiple MCP servers
• Observed across 89 session transcripts and two months; not intermittent

Relationship to earlier reports

This is not the same as #40686 / #40462 (both closed), which described a genuine transport-layer freeze — dropped SSE streams and timed-out MCP calls leaving a hung UI with no feedback.

Here nothing hangs. The turn completes normally and fast. The defect is that the recovery mechanism itself is a no-op, and its failure is silent. Those issues were closed; this behaviour is present today at a measured 100% failure rate.

Related but distinct: #56995 (closed) covered messages sent during execution being silently queued — a sibling problem in the same area (message handling around interruptions), different mechanism.

Method note

Figures were produced by streaming every local transcript, isolating records whose user-role content was exactly Continue from where you left off., then inspecting the following assistant record's stop_reason, text body and tool-call count. Counts are reproducible from the JSONL files with no interpretation required. An initial count of 18 was corrected to 17 after deduplicating one event that appeared in two worktree transcripts.