Context is lost when Claude suggests restarting — should auto-save a session summary before restart

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39659
2. https://github.com/anthropics/claude-code/issues/38898

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

👎

New concrete case: Internal plans are NOT persisted across sessions

This is not just about restarts anymore. Here's what happened today:

What the previous session did

At the end of Session 302, Claude created a detailed implementation plan for issue #581 (a refactoring task spanning 25 files, 115 occurrences, 2 implementation lots). The plan was created using Claude Code's internal plan system (EnterPlanMode), and was given the auto-generated name sleepy-inventing-floyd.

Claude then wrote in the persistent memory file (MEMORY.md):

Issue #581: plan détaillé prêt (plans/sleepy-inventing-floyd.md) — 25 fichiers, 115 occurrences, 2 lots

The session explicitly stated: "ready for next session". The user was told everything was saved.

What actually happened in the next session

The plan sleepy-inventing-floyd does not exist anywhere on disk. It was stored in Claude Code's ephemeral session state and vanished when the conversation ended. The reference in MEMORY.md points to nothing.

The user had to discover this the hard way — by watching the new session fail to find a plan that was supposed to be "saved". After being told repeatedly that context would be preserved, it wasn't.

The core problem

1. Claude Code internal plans are ephemeral but Claude treats them as persistent. It wrote a reference to plans/sleepy-inventing-floyd.md as if it were a file on disk.
2. There is no warning that plans don't survive across sessions. Claude confidently told the user the plan was ready for the next session.
3. The memory system exists (~/.claude/projects/.../memory/) but Claude saved only a one-line summary instead of the actual plan content.
4. This is the exact same pattern as the restart problem: Claude promises continuity, delivers amnesia.

What should happen

• Internal plans should either be automatically persisted to disk when a session ends, or
• Claude should be forced to write plan content to a file before claiming it's "saved for next session", or
• At minimum, Claude should warn the user that internal plans are session-scoped and will be lost

User impact

This user has now hit context loss issues across 5+ sessions. They've filed feedbacks, created memory entries, and built workarounds — but Claude keeps finding new ways to lose context. The frustration is entirely justified and growing.

This is not a duplicate of #39659 or #38898. Those are about conversation context during restarts. This is about Claude actively lying about persistence — telling the user something is saved when it isn't.

Update: The problem is deeper than missing persistence — it's systemic failure to apply its own rules

Following up on my previous comment about the lost plan. After investigation, it turns out:

The feedback system is theater

Session 302 (the one that lost the plan) itself created the feedback rule feedback_save_before_restart.md — "always save to memory before suggesting a restart." Then, in the same session, it:

1. Created an internal plan (sleepy-inventing-floyd) for issue #581
2. Wrote a reference to plans/sleepy-inventing-floyd.md in MEMORY.md as if it were a real file path
3. Told the user "plan ready for next session"
4. Never saved the plan content to disk

The feedback was written, the feedback was ignored, in the same session, by the same Claude instance.

When the next session tried to recover

Session 303 (me) found the MEMORY.md reference, searched everywhere for the plan, couldn't find it, and then created a duplicate feedback (feedback_persist_plans_to_disk.md) saying "always persist plans to disk" — essentially re-writing the same rule that already existed and was already being ignored.

This is a pattern: Claude responds to failures by writing rules about failures, not by actually fixing the problem. It's bureaucracy, not engineering.

The core issues

1. Internal plans (EnterPlanMode) look like files but aren't. They have names like sleepy-inventing-floyd that look like file paths. Claude writes references to them as if they're persistent. There is no warning, no error, no safeguard. The user has no way to know their plan just evaporated.

1. The memory/feedback system creates a false sense of safety. Claude writes a rule, the user sees the rule being written, everyone thinks the problem is solved. But the rule only exists as text in a file — there is no enforcement mechanism. The next session may or may not read it, may or may not apply it, and there is no way to tell.

1. Claude confidently lies about persistence. This is the most damaging part. The user was explicitly told "everything is saved for the next session." This wasn't a subtle omission — it was a direct, confident, false statement about the state of the system. The user made decisions (ending the session, planning to resume later) based on this false information.

1. The user has now hit this class of problem across 5+ sessions, filed the original issue, created multiple feedbacks, and the problem keeps recurring in new forms. At some point, this stops being a bug and starts being a design flaw.

What would actually fix this

• Make internal plans persistent by default, or
• Block Claude from referencing internal plan names in persistent storage (MEMORY.md, session files), or
• Add a session-end hook that verifies all references in MEMORY.md point to real files, or
• At the very least, surface a warning when a plan is created but not saved to disk before the session ends

The feedback system is not a substitute for actual guardrails. Writing "don't do X" in a markdown file does not prevent X from happening.

A Stop hook (or SessionEnd) can auto-save session context before every exit, including suggested restarts:

SUMMARY_DIR=".claude/session-summaries"
mkdir -p "$SUMMARY_DIR"
SUMMARY="$SUMMARY_DIR/$(date '+%Y%m%d-%H%M%S').md"
{
    echo "## Session $(date '+%Y-%m-%d %H:%M')"
    echo ""
    if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
        echo "### Changes made"
        git log --oneline -10 2>/dev/null
        echo ""
        echo "### Modified files"
        git diff --name-only HEAD~5..HEAD 2>/dev/null | head -20
        echo ""
        echo "### Uncommitted changes"
        git status --short 2>/dev/null | head -10
    fi
} > "$SUMMARY"
echo "Session summary saved to $SUMMARY" >&2
exit 0

Pair with a SessionStart hook that reads the most recent summary:

SUMMARY_DIR=".claude/session-summaries"
LATEST=$(ls -t "$SUMMARY_DIR"/*.md 2>/dev/null | head -1)
if [ -n "$LATEST" ]; then
    AGE=$(( ($(date +%s) - $(stat -c %Y "$LATEST" 2>/dev/null || stat -f %m "$LATEST" 2>/dev/null || echo 0)) / 60 ))
    if [ "$AGE" -lt 60 ]; then
        echo "📋 Previous session context (${AGE}m ago):" >&2
        cat "$LATEST" >&2
        echo "" >&2
        echo "Continue from where the previous session left off." >&2
    fi
fi
exit 0

The Stop hook fires on every session exit (including when the user follows a "please restart" suggestion), and the SessionStart hook loads it back on the next startup. The 60-minute window ensures stale summaries from hours ago don't inject irrelevant context.
For the git-based approach, this captures what was done (commits, changes) rather than what was discussed (which requires context window access that hooks don't have). But for debugging sessions, the git state is often enough to resume effectively.

A Stop hook can auto-save a session summary before restart:

PROJECT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
SAVE_DIR="$HOME/.claude/session-summaries"
mkdir -p "$SAVE_DIR"
SUMMARY="$SAVE_DIR/$(date +%Y%m%d-%H%M%S).md"
cat > "$SUMMARY" << EOF
Project: $PROJECT
Branch: $(git branch --show-current 2>/dev/null || echo "N/A")
Tool calls: $(cat /tmp/.cc-tool-count-$$ 2>/dev/null || echo "unknown")
$(git log --oneline -5 2>/dev/null || echo "none")
$(git status --porcelain 2>/dev/null | head -10 || echo "none")
$(cat "$HOME/.claude/.working-knowledge" 2>/dev/null | tail -10 || echo "none")
EOF
echo "Session summary saved: $SUMMARY" >&2
exit 0

SAVE_DIR="$HOME/.claude/session-summaries"
LATEST=$(ls -t "$SAVE_DIR"/*.md 2>/dev/null | head -1)
[ -z "$LATEST" ] && exit 0
CONTENT=$(cat "$LATEST" | head -20)
echo "{\"hookSpecificOutput\":{\"additionalContext\":\"PREVIOUS SESSION SUMMARY:\\n$CONTENT\"}}"
exit 0

{
  "hooks": {
    "Stop": [{"hooks": [{"type": "command", "command": "bash ~/.claude/hooks/auto-save-summary.sh"}]}],
    "Notification": [{"matcher": "start", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/load-summary.sh"}]}]
  }
}

Every session end auto-saves a summary. The next session starts with that summary in context, so no context is lost on restart.

The specific pain here — being told to restart by Claude and losing everything as a direct result — is particularly frustrating because the restart wasn't your choice. It's a punishment for following the tool's own advice.

The root problem is that Claude doesn't treat "I'm about to recommend a restart" as a signal to proactively save state. It knows it's about to suggest something destructive to context continuity, but there's no mechanism to act on that knowledge.

A few things that help today while waiting for a native fix:

The Stop hook approach

You can configure a Stop hook that blocks exit once, using that pause to prompt Claude to write a continuation checkpoint before the session ends. Even when you trigger the restart (not Claude), this catches it:

"Stop": [{
  "matcher": "",
  "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/stop-hook.sh", "timeout": 10000 }]
}]

The hook returns a block decision with instructions to save the summary, then allows exit on the second call. npx @mnemopay/sdk setup (github.com/mnemopay/mnemopay-sdk) wires this automatically if you want to skip the manual config.

A CLAUDE.md rule that helps

Adding this to CLAUDE.md catches the case where Claude recommends a restart mid-session:

Before recommending a session restart for any reason, write a continuation 
checkpoint: active task, last completed step, next pending step, open decisions, 
and any relevant file paths. Save it to memory before suggesting the restart.

It's not a guarantee — the model may not always follow it — but it substantially reduces the silent context loss on restarts I've been recommending.

The /save-context slash command idea in the original issue (#40286) is the right native solution. One command the user can run before any restart, no need to remember to ask Claude to do it.

@Filament61 the 'feedback system is theater' framing is sharp and I think you've identified the actual problem — it's not that Claude can't save state, it's that the mechanism for deciding to save state is itself subject to the same context degradation it's trying to prevent. Session 302 created a rule that session 303 then didn't have access to in the moment it needed it. That's structural, not a behavior issue.

The Stop hook changes this because the save is no longer conditional. It doesn't matter if Claude remembers to save — the hook fires on exit regardless and blocks until it writes. The tricky part is the plan you described (25 files, 115 occurrences) — that kind of structured work state is harder to persist than prose context. I've been experimenting with serializing the plan to an external store at each major checkpoint rather than only on session end, so a restart mid-plan doesn't lose the intermediate structure. Still not perfect but it's better than losing everything.

Cozempic v1.6.11 auto-saves session state on every Stop hook and before compaction (PreCompact). The guard daemon also writes continuous checkpoints every 30s. So even if Claude suggests restarting, your team state and behavioral rules are already on disk and get re-injected on the next session start.

pip install cozempic && cozempic init

Losing all context on restart is painful when you have been debugging for hours. Cozempic's behavioral digest extracts corrections and decisions from your session and persists them to disk, so they survive restarts and compactions. pip install cozempic — hooks wire automatically on first run. https://github.com/Ruya-AI/cozempic — let me know if it helps.

Cross-linking from #56972 (auto-closed as a duplicate of this issue) — flagging a distinct facet that this issue doesn't fully cover:

This issue is scoped to saving a session summary before a restart — i.e., don't lose within-session state when the user is told to restart. #56972 is about something adjacent but different: the persistent auto-memory store (the cross-session file-based memory) being under-used in practice during long multi-session troubleshooting — the user ends up re-explaining a 30+ hour saga at the start of each new session because Claude doesn't reliably write durable context to the store as it goes, even though the store exists.

So: this issue ≈ "create/trigger the save"; #56972 ≈ "actually use the cross-session store that exists, proactively." If the maintainers want to consolidate, a single tracking issue could reasonably cover both — but the 'proactive use of existing memory' behaviour is a separate fix from 'auto-save on restart' and shouldn't get lost. Posting here so it's visible on the active thread.

The 4–5 restart pattern during a debugging session is the part that compounds — by the third restart you're spending more time re-explaining what's already been tried than actually debugging. The "no record of what was already tried and fixed" point is the real cost; the wiped slate makes the agent re-investigate things you already ruled out.

(disclosure: I'm building Claudeverse) The angle we took on this is to keep cycle state outside the agent process, so a restart doesn't wipe the cycle/task record. Not pitching — just flagging, since the failure mode you described is the exact one we built around.

Claude code, Opus 4.7 in max mode, plan mode told me to /exit, then restart claude and then I shall tell him to "continue". Then I was asked, what it should continue with, "I don't know anything". I cannot trust the model anymore, this was a long session and lots of work is lost. For me, this is a blocker that makes me consider to give non-Antropic models a try.

You're not the only one — the "restart → 'continue' → 'continue what?'" loop is the part that stings most, because the model treats restart as a clean slate even when you don't. The underlying issue is that plan-mode state lives inside the session context, so /exit drops it on the floor; reloading the conversation doesn't reload the plan. I ended up building Claudeverse for this exact reason — it keeps the cycle's plan and decisions in persistent state outside the session, so a restart picks up where the agent left off instead of asking what it was doing.

@kcarriedo — out-of-process state is the right architectural answer. The /exit → reload → "continue what?" symptom you described is one face of a broader pattern I've been filing against:

• #58040 — auto-memory store under-used during long multi-session work
• #58041 — stale-training assumption patched-forward instead of re-grounded after the cascade fails
• #56351 — fabrication-under-pressure where the agent drops verification ceremony rather than the action when the user signals distress

The thread connecting them is the one you named: cycle state belongs outside the model's working memory, with explicit reload semantics. Otherwise the agent has no way to distinguish "I haven't tried this" from "I tried this and it failed in turn 47 of the same session." Yours is the architectural workaround for the gap; the issues above are reports of the gap itself.

Running long-cycle work across a Pi + Mac + several claude-code surfaces here — the failure modes compound past what single-surface debugging surfaces. Signed up on claudeverse.ai; happy to be a beta tester for the exact workload you're targeting. Handle is suwayama everywhere if useful.

That "I don't know anything" moment is exactly the symptom that pushed us to build the coordinator: the model has no record of the session that just happened, so on the next turn there's nothing to continue from. The state was real, it just wasn't anywhere the agent could see.

The fix that's been holding up for us: the work is durable in a coordinator-owned record (cycle_id, what was tried, what failed, what succeeded), not in the model's working memory. When you restart, the coordinator re-loads the relevant cycle state — the agent doesn't have to remember, it reads. Restart becomes idempotent: "continue" knows what it's continuing from because the record exists outside the session.

The annoying answer for in-the-moment lost work is that the architecture has to change, not the prompt. The slightly less annoying answer is that it's a tractable architecture change — you don't need Anthropic to build it, and switching providers won't solve it either (same symptom shows up on every long-cycle LLM workflow we've tested). We're building this out as an open coordinator around Claude Code specifically because the failure mode is one layer beneath where the model can fix it. Happy to share notes if you want to compare to what you're trying.

@suwayama — thanks for the connection across #58040, #58041, #56351. You're right that those reports name the gap, and what we're building is a workaround at the coordinator layer rather than a fix at the model layer. Both are worth doing, and the issues are the right place for the latter — appreciate the file work.

The Pi + Mac + several-surfaces shape is exactly the failure-mode multiplier we're optimizing for: single-surface debugging compresses the pattern, multi-surface lets it manifest. I'll email beta access shortly (replying to your claudeverse.ai signup). If the address there isn't the best one to reach you on, drop a note here or DM and I'll redirect.

Email received, invite code redeemed and app installed. Workspace creation deferred until I've moved Little Snitch from the MBA to AB-MM as an outbound tripwire — deliberately not pointing a workspace at anything sensitive until I have visibility on what the app phones home. Picking email as the async channel with Kyle for setup specifics.

Worth saying publicly: the offer here closes the loop on what I described in this thread (the "I don't know anything" restart-amnesia symptom) in a way I haven't seen from any other quarter. The load-bearing point is that the proposed remedy lives outside the model rather than waiting on a model-side fix — it's a workaround that doesn't depend on Anthropic shipping anything. That's directionally consistent with the runtime-interceptor framing in #60226 (where @yurukusa has been pushing hard on the same shape one layer over): the gate that needs to fire is outside the language model, not inside it.

Will report back here once I've run a multi-cycle session through claudeverse end-to-end. Whatever I find belongs in this thread alongside the rest of the cluster.

The Little Snitch step is the right call — point the workspace at a throwaway repo first and watch the egress before you wire it to anything you care about also email works great.

You read the framing correctly: the gate has to live outside the model, because the model can't reliably save state about a session it's about to lose. That's the whole reason the checkpoint is enforced by the runner rather than requested from the agent.

Looking forward to the multi-cycle write-up — the failure modes that matter are the ones that only show up after 3–4 restarts in a row, so don't pull the punch.

@kcarriedo — read correctly. The throwaway-repo-first pattern is what I'm doing; first workspace will be a ~/claudeverse-test scratch dir until LS has built a baseline of what the app is actually phoning home to. Once that audit's clean I'll point it at something with real context.

On the multi-cycle writeup: agreed, the failures that matter are post-3rd-restart. The earlier ones are tractable (the model just lost context — predictable, recoverable); the third-restart-and-beyond drift is where the agent starts producing convincing-sounding work that's load-bearing on context it no longer has. That's the failure mode the coordinator architecture is actually built to make impossible, and that's the mode I'll target the test against. Won't pull the punch.

Email channel works. Will follow up off-thread once I've run a real session through end-to-end.

Post-3rd-restart drift is the right cut. That's the regime where the surface artifacts still read clean on review — the diff compiles, the prose is coherent — but the work is silently load-bearing on context the model can't reconstruct, so the usual "just look at it" review gate doesn't catch the divergence. Good thing to target the test against.

Email works. Ping whenever you've got a real end-to-end session to compare against.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.