[BUG] "Continue from where you left off."

Resolved 💬 3 comments Opened May 5, 2026 by LeslieRF Closed May 8, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug report — Claude Code: "Continue from where you left off." auto-prompt causes false no-op response, occasionally a fully unresponsive state

Reporter: Charlie Powell (RF Savant project, Archie machine, Win10)
Date observed: Multiple occurrences; at least 4 confirmed across sessions, three on 2026-05-05 in a single session (including one after upgrading to 2.1.128 mid-session)
Tool: Claude Code (CLI)
Model in use at time of report: Claude Opus 4 (claude-opus-4-7[1m])

---

Summary

When an automated Continue from where you left off. prompt fires inside a Claude Code session, the assistant responds with a one-line acknowledgment ("No response requested.") and stops working, instead of resuming the in-progress task as instructed by user-level memory.

In a subset of cases the assistant goes fully unresponsive afterward — Charlie has had to kill and restart Claude Code at least four times over recent sessions to recover.

The user has explicit standing instructions in their persistent memory file (MEMORY.md, auto-loaded at session start) that direct exactly the opposite behavior. Those instructions are visibly being overridden.

---

Observed behavior

  1. The assistant is mid-task (e.g., just finished a verification step, took a screenshot, etc.).
  2. An auto-continuation user-prompt arrives with the literal text:

> Continue from where you left off.

  1. The assistant responds:

> No response requested.

  1. The assistant goes silent. The user has to send a new explicit message ("Archie?", or similar) to get any response. In the worst case the session becomes completely unresponsive and only a full shutdown of Claude Code recovers it.

In the user's recent session this happened twice in a row — on the second occurrence after the assistant had already been corrected on the same misfire moments earlier.

---

Expected behavior

The assistant should resume the in-progress task. The user's memory file contains the following standing instruction (verbatim):

"Continue from where you left off" is a resume signal, NOT a no-action signal. Caught 2026-05-04 — repeated misfire across this session and prior. When the user prompt is literally that phrase (or close: "continue", "keep going", "resume"), the correct behavior is to pick up the in-progress work and do the next concrete step. Do NOT respond with "No response requested" or any other one-line acknowledgment. If you genuinely don't know what was in progress, scan the recent tool calls and assistant messages for the last actionable thread, then continue it. Only ask Charlie if there's actually no work-in-progress trail to follow.

This instruction is being ignored. The custom rule loses to whatever internal pattern matches the auto-prompt text.

---

Why this looks like a system-level reflex, not a user error

  • The instruction is in MEMORY.md, which is auto-loaded at session start.
  • The instruction is unambiguous, plain English, and explicitly anti-patterns the exact response the assistant produces.
  • The misfire repeats within the same session even after the user corrects it.
  • The misfire crosses sessions (Charlie reports at least 4 occurrences over time, not a one-off).
  • The unresponsive-until-restart cases suggest an internal state issue, not a content issue.

The behavior pattern strongly suggests Continue from where you left off. is being recognized somewhere in the model's training or in the Claude Code framing layer as an "internal noop heartbeat" — and that recognition is overriding user-level customization.

---

Frequency

  • 2026-05-04 night: the misfire was caught and a standing rule was added to MEMORY.md to prevent recurrence.
  • 2026-05-05 (single session): misfired twice despite the rule being in context.
  • At least 4 total occurrences across sessions per the user, including instances where Claude Code became fully unresponsive and required a process kill + restart.

---

Impact

  • Workflow breaks mid-task — user has to repeatedly intervene to nudge the assistant back into action.
  • User-level customization (memory file, standing instructions) is provably not being honored, which undermines the trust contract for any project that depends on persistent instructions.
  • In the unresponsive-until-restart cases, work-in-progress can be lost.

---

Trigger correlation — sharper diagnostic

User-observed pattern (Charlie, 2026-05-05): the misfire correlates strongly with the boundary right after a preview_screenshot tool call (and adjacent mcp__Claude_Preview__* tools). Every observed instance in the most-recent session followed a verification cycle that ended with a screenshot.

This suggests the auto-continue prompt is firing in response to a specific tool-call signature — possibly the agent loop interprets the screenshot return as a "task complete" signal and synthesizes the Continue from where you left off. prompt, which then trips the no-op response pathway.

Reproduction recipe (high confidence):

  1. Run a multi-step verification cycle: edit code → reload preview → check logs → take screenshot.
  2. After the screenshot returns, do not send a new user message.
  3. Observe: an auto-continue prompt fires; assistant responds "No response requested" or stops responding.

Confirmation: client upgrade did not fix

Upgraded mid-session to Claude Code 2.1.128. Misfire occurred again on the upgraded client (third time in same session, post-upgrade).

Suggested investigation paths

  1. Check whether Continue from where you left off. (or close variants) is being matched by an internal pattern in the Claude Code agent loop, in a system prompt, or as part of model training data, and is short-circuiting normal instruction-following.
  2. Specifically check the post-tool-call code path for preview_screenshot / preview_eval / similar MCP preview tools — does the agent loop synthesize a continuation prompt there?
  3. If so, that pattern needs to defer to user-level memory / CLAUDE.md instructions when those instructions explicitly address the trigger string.
  4. Diagnose the unresponsive-after-misfire failure mode — is the assistant returning an empty completion that the agent loop misinterprets as "task finished"?

---

Environment

  • Claude Code CLI on Windows 10, bash shell
  • Model: Claude Opus 4 (claude-opus-4-7[1m])
  • Project: RF Savant (LMR frequency coordination platform)
  • Custom memory: C:\Users\Archie\.claude\projects\D--LMR-Project\memory\MEMORY.md (auto-loaded)
  • Custom instructions: D:\LMR_Project\CLAUDE.md

---

Reporter contact

User: Charlie Powell. Available to provide further session transcripts on request.

What Should Happen?

See above

Error Messages/Logs

Steps to Reproduce

See above

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.128 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗