On resume, recent work is gone and the session reverts to the last rename point (CLI, Windows 11)

Yes, this pattern shows up periodically, and the detail you noticed — resume reverts to the state at the last rename — is the useful clue. The good news first: your recent work is very probably not gone. It's almost certainly still on disk in the session's transcript, even though resume isn't showing it.
Here's why. Claude Code keeps two separate things:

• the transcript at ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl — this is append-only; every turn (including the ones after a rename) gets written as a new line and isn't rewritten,
• and a small amount of session metadata kept separately (status/index state).

When resume reconstructs to "the last rename point" rather than your latest turns, that lines up with resume reading a cached/index state that was last snapshotted around the rename, while your live work kept appending to the .jsonl. I can't confirm the exact resume logic from the outside, so treat that as a hypothesis — but the part that matters to you is verifiable: the turns are in the .jsonl.
Check it (Windows, PowerShell):

Get-ChildItem "$env:USERPROFILE\.claude\projects" -Recurse -Filter *.jsonl |
  Sort-Object LastWriteTime -Descending | Select-Object -First 5 FullName, LastWriteTime
$f = "C:\path\to\that\<session-id>.jsonl"
(Get-Content $f).Count
Get-Content $f -Tail 20

If the last lines contain your recent prompts/responses (after the rename), the work is intact — resume just isn't replaying the full file. You can read the content straight out of the .jsonl in the meantime.
For the needs-repro label, a candidate sequence to try (since it correlates with rename): start a session → do work → rename it → do more work → /exit → resume. If it reverts to the rename point, that isolates rename as the trigger.
This is the same family as the other "present on disk but not shown after resume" reports (e.g. #61952), where the transcript survived and only the index/metadata view was stale.
Going forward, a SessionStart/PreCompact hook that copies the .jsonl to a location outside ~/.claude/projects gives you a safety net regardless of what resume does — there are ready-made ones in cc-safe-setup if useful.

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/60984

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

Seen this. The trap is that the "work" only lived inside the session/conversation state, so when the resume reattaches to an older rename point the recent turns are gone with it. The fix that makes it a non-issue: stop trusting session memory as your save. Have Claude commit to git (or even just copy the files) at every working checkpoint, so a bad resume costs you a "git checkout" instead of a morning. I keep a short pre-flight list for exactly this kind of thing if it helps: guima.ai/safety

I worked out what's causing this, at least my version of it, and there's a fix.

First, the important part for most people: if you just open a terminal and type claude --resume, you're probably fine. This doesn't seem to hit normal command-line resume. It hits when Claude is started by something else: a wrapper script, an editor extension, or a custom session-manager tool. In my case it was a little session tracker app I built that launches and resumes my Claude sessions for me. That's what surfaced it.

What it looks like: you work in a session, close it, reopen it, and the recent work is gone. It jumps back to the moment you last renamed the session.

What's really happening: Claude normally saves your conversation to a file on disk as you go. But when it's started this way, it comes up in a kind of "background helper" mode and quietly stops saving. Everything looks totally normal on screen, so you don't notice. The only thing that did get saved was from earlier, the last time you renamed the session (renaming forces a save). So on reopen, that rename moment is the newest thing on disk and Claude loads it. Everything after is gone, because it was never written down. This is worse than it being hidden. It was never saved.

Why it happens: while Claude is running, it sets some hidden "I'm already running" flags in the background. Normally those don't matter. But if another program starts a new Claude while those flags are still set, the new Claude inherits them, assumes it's just a helper for an existing session, and turns its saving off. Type the command yourself in a clean terminal and the flags aren't there, so it saves fine. That's exactly why plain CLI resume works and launching through a tool doesn't.

How to confirm it's this: a normal session writes a small "I'm alive" file under ~/.claude/sessions/ and its conversation file keeps growing as you type. A broken one does neither: no alive file, and the conversation file stays frozen at its opening size even after ten minutes of work.

The fix: if you launch Claude from your own tool or script, clear those flags before starting it. If you don't use a launcher, you probably never hit this at all.

I think this is also behind #60984, where the editor extension spawns Claude (which inherits the same flags) and the conversation files end up with only the title and none of the messages. Same mode, same result.

---

For devs / anyone debugging (the technical bits):

• The "flags" are environment variables: CLAUDECODE, CLAUDE_CODE_CHILD_SESSION, CLAUDE_CODE_SESSION_ID, AI_AGENT, and other CLAUDE_CODE_* vars. Any process spawned from within Claude inherits them, and a claude --resume launched with them set runs degraded.
• Repro: launch claude --resume <id> with CLAUDECODE / CLAUDE_CODE_CHILD_SESSION set; use it; note no marker in ~/.claude/sessions/ and a frozen transcript. Clear those vars, relaunch, and a marker appears within seconds (kind:"interactive") and the transcript persists.
• Programmatic fix: unset CLAUDECODE, all CLAUDE_CODE_*, and AI_AGENT before spawning claude from a launcher/wrapper/extension.
• Suggested upstream fix: an interactive claude (including --resume) should persist its transcript regardless of inherited CLAUDE_CODE_* vars, or expose a flag to force a top-level interactive session.
• Verification note: live-registration restore is confirmed end to end; persistence is gated by the same interactive-session check. Prime suspect var is CLAUDECODE or CLAUDE_CODE_CHILD_SESSION; I cleared the whole group at once.

Closing. Root cause and fix posted above; this is the same underlying failure as #60984.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.