[Bug] Plan mode resurfaces old plans after session compaction with Claude 4.5 Opus

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/10528
2. https://github.com/anthropics/claude-code/issues/8544
3. https://github.com/anthropics/claude-code/issues/11582

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

I am consistently seeing the same issue - even without session compaction. Sometimes a plan gets executed, then a new prompt/task gets asked, but the latest plan shows the right new task PLUS the entire old plan which has already been finished. Now I need to explicitly ask it to drop the old plan in order to switch to new plans - this is very annoying. Possibly a combination effect of recent ~/.claude/plans/* file updating and Opus 4.5. It's not very easy to isolate the root cause or even write reproducible steps for this. But it's not a corner-case bug, it's happening after almost every single long plan execution.

I can confirm this is happening even without ever compacting the session. It regurgitates the whole plan every time it wants to suggest something else in Plan Mode. As @taiyangc suggested, I think it's because of the usage of .md files inside the plans folder. Because of this, it's difficult to follow exactly what changes Claude Code will do next as it shares the whole plan from the start of the conversation.

Confirming that this is happening every time I make changes to plans in Plan Mode within the same session. SO annoying.

I can confirm, I'm seeing this happen over and over starting this week. It seems it reads the old plan's .md file.
Steps to reproduce:

• Ask it to create any plan - it will write a .md file
• Execute the plan
• Ask for any follow-up task in plan mode. It will show the whole plan again, it makes it impossible to know what it intends to do for the follow-up task.

For now, I'm asking it directly to scratch the previous plan.

The plan that is shown in Plan mode is not being cleaned up or updated, at least visually, and it's getting hard to follow.

It is not just after compaction, but it also happens after switching back to plan mode.

plan mode -> auto accept -> stop claude -> plan mode = old plan shown

Additional reproduction: Session resume (no compaction)

Same symptom occurs on session resume without any compaction involved.

Environment

• Version: 2.0.55
• Model: Opus 4.5
• Platform: Linux
• Session: Resumed from previous session

Reproduction

1. Session A: Enter Plan Mode, write plan for Task A (e.g., "Enable tabular numbers in Clock"), exit plan mode
2. Continue in Session A working on other tasks
3. Resume session (Session B)
4. Work on Task B (e.g., "Fix NetworkMonitor padding")
5. Enter Plan Mode, Claude identifies correct solution for Task B verbally
6. Claude calls ExitPlanMode
7. Bug: Old plan file content (Task A) is presented to user, not Task B
8. User rejects, Claude re-explains Task B solution
9. Claude calls ExitPlanMode again
10. Bug: Same stale Task A plan presented again
11. Loop continues until user forces Claude to delete the plan file

Root cause hypothesis

The plan file (~/.claude/plans/*.md) persists across sessions. When Plan Mode is entered in a resumed session, Claude doesn't read/validate existing plan file content before calling ExitPlanMode. Claude describes the correct new solution verbally but the system presents the stale file content.

Workaround

User must explicitly ask Claude to delete the plan file, then Claude writes fresh content.

The #12988 I just created asks to address a broader need to be able to tell Claude "You are to no longer concern yourself with the previous task in any way, you are now working on a different but related new task" (with implications including new planning file, as well as no longer talking about old task in progress reports, in /compact summaries, etc).

GitHub Comment for Issue #12505

Post this to: https://github.com/anthropics/claude-code/issues/12505

---

Additional Reproduction Details & Root Cause Analysis

I've been experiencing this issue consistently in moderate-length sessions (1-2 hours) when working on multiple features. After investigating my local ~/.claude/plans/ directory, I've identified the underlying mechanism.

What I Found

My plans directory contains 285 accumulated plan files totaling 2.1MB. Examining the file structure reveals the issue:

# Plan: Current Task
[current plan content]

---

# Previous Plan: Earlier Task (now completed)
[old plan content that shouldn't be relevant]

---

# Previous Plan: Even Earlier Task
[more old content...]

Key observations:

1. Plan files persist indefinitely - No TTL or cleanup mechanism exists
2. Plans concatenate within sessions - Multiple planning tasks append to the same file with # Previous Plan: headers
3. No session binding - Plan files have random names (compressed-nibbling-porcupine.md) with no session ID association
4. Survives compaction - Session compaction doesn't invalidate or clean up plan file references

Reproduction Pattern

1. Start a session, enter plan mode for Task A → plan file created
2. Implement Task A, return to normal mode
3. Work on Task B, enter plan mode again → same plan file updated with # Previous Plan: header
4. Session compacts due to context length
5. Enter plan mode for Task C → Claude reads full plan file including completed Tasks A & B
6. Claude inappropriately references completed plans as if they're current

Proposed Fixes

1. Session-scoped plan files (recommended)

~/.claude/plans/
  {session-id}/
    {timestamp}-{slug}.md

Plans are deleted or archived when session ends.

2. Plan file metadata

---
session_id: abc123
created_at: 2026-01-01T14:30:00Z
status: active | completed | superseded
---

Only load plans where session_id matches current session and status: active.

3. PrePlanMode hook (see #14259)
Allow users to run cleanup before entering plan mode:

{
  "hooks": {
    "PrePlanMode": [{
      "type": "command",
      "command": "rm -f ~/.claude/plans/*.md"
    }]
  }
}

4. Explicit plan versioning
Replace # Previous Plan: concatenation with structured versioning that marks old plans as superseded so the model knows to ignore them.

Current Workaround

For others experiencing this, here's what works:

# Add to ~/.zshrc or ~/.bashrc
alias claude-fresh-plan='rm -rf ~/.claude/plans/*.md && echo "Plans cleared"'

# Or auto-clean old plans on terminal start
find ~/.claude/plans -name "*.md" -mtime +1 -delete 2>/dev/null

Environment

• Platform: macOS (darwin)
• Version: Latest
• Session length: 1-2 hours with multiple feature context switches

This issue significantly impacts workflow when doing iterative development across multiple features in a single session. Happy to provide more details or test proposed fixes.

@bcherny

Confirming with Forensic Evidence

I can confirm this bug with detailed forensic analysis from conversation logs. Our experience adds concrete evidence to what @benabraham hypothesized:

The plan file (~/.claude/plans/*.md) persists across sessions. When Plan Mode is entered in a resumed session, Claude doesn't read/validate existing plan file content before calling ExitPlanMode.

What We Experienced

A single session (a1b5968e-...) persisted from Jan 13 → Jan 15 (across multiple days due to session resumption). During this time, 9 completely different plans were written to the same file (recursive-churning-octopus.md):

| Timestamp | Plan Title | Action |
|-----------|------------|--------|
| Jan 13 17:45 | NLP-to-JSON Filters | CREATED |
| Jan 13 18:23 | NLP-to-JSON Pipeline - Simplified | OVERWRITE |
| Jan 13 19:43 | Ambiguity Handling Redesign | OVERWRITE |
| Jan 15 00:23 | Git Repository Setup | OVERWRITE ← Different task! |
| Jan 15 00:32 | Ambiguity Handling | OVERWRITE |
| Jan 15 00:38 | Git Repository Setup | OVERWRITE |
| Jan 15 01:06 | Git Version Tag Replacement | OVERWRITE |
| Jan 15 01:14 | Git Repository Setup | OVERWRITE |
| Jan 15 01:32 | (test writes) | OVERWRITE |

Forensic Method

Analyzed the 14MB JSONL conversation log:

grep -c "recursive-churning-octopus" session.jsonl  # → 2947 references
grep "Write" session.jsonl | grep "plans" | wc -l   # → 56 Write operations

Found 14 distinct Write tool calls to the same plan file — confirming @felipefreitag's observation:

It seems it reads the old plan's .md file. Ask it to create any plan - it will write a .md file. Execute the plan. Ask for any follow-up task in plan mode. It will show the whole plan again, it makes it impossible to know what it intends to do for the follow-up task.

Key Finding: Session Slug Reuse

The session slug (recursive-churning-octopus) is generated once per session and reused for ALL subsequent plan mode entries. This means:

• ✅ Different sessions = Different plan files (works correctly)
• ❌ Same session + multiple plans = OVERWRITE (this bug)

Related Issues

This bug is connected to several other plan mode issues:

Cross-referenced to this issue:
#12778, #12827, #12838, #12988, #13114, #13539, #13641, #13716, #13740

Other plan mode bugs:

• #16338 — Plan mode session resume doesn't allow editing
• #14004 — Claude executes edits without user approval
• #13182 — Plan mode acceptance UI issues
• #18248 — Interactive mode toggle not working
• #17344 — Plan mode missing from mode cycle on Windows
• #17489 — Mode cycling completely broken in v2.1.3

Partial Fix in v2.1.3

The changelog notes:

Fixed plan files persisting across /clear commands, now ensuring a fresh plan file is used after clearing a conversation

This addresses only the /clear case — the core bug (multiple plans in same session without /clear) remains.

Supporting the Proposed Fixes

Agreeing with @Tigres2526's suggestions and the workarounds shared by @aayush-exe and @bluecon — the cleanest permanent fix would be:

Each new plan request created a fresh file instead of reusing

Perhaps appending a counter or timestamp to the slug: recursive-churning-octopus-2, recursive-churning-octopus-3, etc.

---

Environment: Claude Opus 4.5, Linux (Ubuntu), Claude Code CLI 2.1.7
Feedback ID: 7c02bc81-4ce7-4d67-b003-1bb4c1ef4272

Glad to see this is still open. Sad to see that it's still happening two and a half months later.

I closed my duplicate report. But here's the description since it's rather more concise:

I've used Claude Plan Mode to create a plan. When the plan runs out of context and there's not enough context to say compact, I say /new, abd then I tell it to look at what progress has been made on the current plan and then continue executing it.

The problem is that it can't identify what the current plan is, and so it searches around in the repository to find what plan it might be and pretends that that's the right thing to do. It doesn't warn me that it can't find the plan. It doesn't know to look in my ~/.claude/plans folder where it saves plans. That sounds like a bug.

Still reproducing on v2.1.44

Environment:

• Claude Code v2.1.44 (native installer, not npm)
• Ubuntu 24.04 (Linux 6.8.0-60-generic)
• Model: Opus 4.6

Behavior: /resume (or --resume) restores the conversation to the point where the last plan was presented for approval, rather than the actual end of the conversation. This has happened across multiple versions, not just the current one.

Workaround: Clearing ~/.claude/plans/*.md before resuming avoids the issue, but this shouldn't be necessary.

This is still a significant workflow disruption — adding my confirmation to keep this from going stale.

Just happened to me again.

happened to me too right now, but there was no compacting

A UserPromptSubmit hook can detect and clear stale plan references after compaction:

PROMPT=$(cat | jq -r '.userPrompt // empty' 2>/dev/null)
if echo "$PROMPT" | grep -qiE '(the plan|our plan|current plan|execute plan|follow plan)'; then
    COMPACT_MARKER="/tmp/cc-last-compact"
    if [ -f "$COMPACT_MARKER" ]; then
        AGE=$(( $(date +%s) - $(cat "$COMPACT_MARKER") ))
        if [ $AGE -lt 600 ]; then  # Within 10 minutes of compaction
            jq -n '{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"⚠️ Context was recently compacted. Any plan referenced may be from a previous session state. Re-read the plan file to verify it is current before executing."}}'
            exit 0
        fi
    fi
fi
exit 0

Pair with a PreCompact hook that saves the active plan:

date +%s > /tmp/cc-last-compact
for f in task_plan.md plan.md .claude/plan.md; do
    if [ -f "$f" ]; then
        cp "$f" "/tmp/cc-plan-backup-$(date +%s).md"
        echo "Plan backed up before compaction: $f" >&2
    fi
done
exit 0

And a post-compaction reinject:

COMPACT_MARKER="/tmp/cc-last-compact"
REINJECT_MARKER="/tmp/cc-plan-reinjected"
[ -f "$COMPACT_MARKER" ] || exit 0
[ -f "$REINJECT_MARKER" ] && exit 0
LATEST=$(ls -t /tmp/cc-plan-backup-*.md 2>/dev/null | head -1)
[ -z "$LATEST" ] && exit 0
touch "$REINJECT_MARKER"
jq -n --arg plan "$(cat "$LATEST")" '{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"Active plan (restored after compaction):\n" + $plan}}'
exit 0

This is still a problem on 2.1.92 (Claude Code). It's kind of insane it's lasted so long.

Claude Code for VS Code plugin v. 2.1.101 - same problem.

Fun fact: Claude Code itself referred me to this ticket, so I'll also be waiting here for the solution.

This is happening so often that I'm looking into alternative tools. I'm on version 2.1.104. It's becoming unusable