Desktop rewind fails on conversation-only sessions: not on active chain (chain size 2/N)

[pudDesign]

Preflight Checklist

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

What's Wrong?

In Claude Desktop, rewinding to any message in a conversation-only session (no Edit/Write tool use) fails. Per the official checkpointing docs, "every user prompt creates a new checkpoint" — but rewind rejects all targets in conversation-only sessions.

Log signature in %APPDATA%\Roaming\Claude\logs\main.log:

[Rewind] target=<uuid> → assistantUuid=<uuid> not on active chain for <session> (chain size 2/N)

The "2" is constant regardless of N (observed N = 9, 117, 143).

Bisection (ruled out)

• ✅ Standalone CLI (claude v2.1.131) rewinds correctly in the exact same folder
• ✅ Sessions with Edit/Write tool use rewind correctly in Desktop
• ❌ Brand new sessions, brand new folders, both C: and I: drives — all fail
• Plugin hooks not the cause (only PostToolUse on Edit|Write registered; doesn't fire in failing sessions)
• Cross-drive not the cause (same failure on C:)
• Folder rename / migration not the cause (brand new folder fails identically)
• No EXDEV/EPERM/ENOENT errors in main.log

Hypothesis

Desktop's LocalSessions.rewind validator builds an "active chain" of size 2 (latest user + assistant turn) when no file-history snapshot anchors exist, rejecting earlier messages as out-of-chain. The standalone CLI uses a different rewind path and is unaffected.

Possibly relevant

Cowork bridge state shows empty processedMessageUuids / pendingProcessedAcks arrays. If the active-chain definition requires Cowork-acknowledged messages, that could explain the constant chain size 2.

Environment details

• Claude Desktop 1.7196.0.0 (Windows 11, MSIX install)
• Bundled CLI: 2.1.138 (not directly testable — MSIX-sealed)
• Standalone CLI: 2.1.131 (works correctly in same scenario)
• Cowork / remote control enabled

What Should Happen?

Per the official checkpointing docs, every user prompt creates a new checkpoint, so rewinding to any earlier user message in a conversation-only session should succeed — matching the behavior of the standalone CLI (v2.1.131) in the same folder.

Error Messages/Logs

Steps to Reproduce

1. Create a fresh empty folder.
2. Open it in Claude Desktop and start a new session.
3. Have a brief text-only exchange (3+ user messages, no file edits).
4. Press Esc Esc, pick any earlier message.
5. Observe: "Can't rewind to this message".

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.138 (bundled in Claude Desktop 1.7196.0.0); also tested standalone 2.1.131

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Desktop 1.6608.0 (macOS): All rewind attempts rejected with "Can't rewind to this message" — regression after auto-update #57206
2. [BUG] Rewind option visible in picker but selecting any anchor returns 'Can't rewind to this message' (v2.1.119, CLI) #57601
3. [BUG] Desktop app cannot rewind the first message. #50780

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

[pudDesign]

Thanks for the auto-triage, but I don't think this is a duplicate of any of the three linked issues — leaving a note so the bot doesn't auto-close it.

• [BUG] Claude Desktop 1.6608.0 (macOS): All rewind attempts rejected with "Can't rewind to this message" — regression after auto-update #57206 is closed as not-planned; the OP traced their case to a third-party plugin's Stop hook injecting content into the session. I've explicitly ruled plugin hooks out here (the only PostToolUse hook registered is on Edit|Write and doesn't fire in failing sessions; behavior also reproduces with hooks disabled).

• • [BUG] Rewind option visible in picker but selecting any anchor returns 'Can't rewind to this message' (v2.1.119, CLI) #57601 (CLI v2.1.119, macOS) is about long sessions with prior tool calls / user-interrupted tool uses, and the follow-up comments trace it to prior rewinds orphaning post-anchor messages (many disconnected JSONL roots, e.g. 1/371, 7/92). My repro is on brand-new sessions with no prior rewinds and no tool use at all.
• • • [BUG] Desktop app cannot rewind the first message. #50780 originated as a first-message-only Desktop bug; recent comments on that thread describe a different trigger (thinking + tool_use turns producing split JSONL entries, or image attachments). Neither applies here — failing sessions are pure text with no thinking+tool_use splits and no attachments.
      What's distinct about this report:

• Reproduces on conversation-only sessions (no Edit/Write tool use), on brand-new folders, on both C: and I: drives.

• • Log signature is not on active chain with chain size 2/N where the "2" is constant regardless of N (observed N = 9, 117, 143) — i.e., only the latest user+assistant turn is ever considered on-chain.
• • • The standalone CLI (v2.1.131) rewinds correctly in the exact same folder, isolating the regression to Desktop's bundled rewind path (LocalSessions.rewind), not the JSONL on disk.
• • • • No EXDEV/EPERM/ENOENT errors, no cross-drive issue, no folder migration involved.
        Hypothesis (repeating from the issue body for visibility): Desktop's LocalSessions.rewind validator builds an active chain of size 2 (latest user + assistant turn) when there are no file-history snapshot anchors, rejecting all earlier messages as out-of-chain. Sessions with Edit/Write tool use rewind correctly in Desktop, which is consistent with snapshot anchors being what the validator currently keys off of.

Keeping the issue open. Happy to attach a minimal failing session JSONL + main.log excerpt if that would help.

[pudDesign]

Updated hypothesis (revising my earlier snapshot-anchor theory)

After more investigation I think the root cause isn't really about snapshot anchors — it's about how the active chain is constructed in the first place.

Desktop's LocalSessions.rewind "active chain" appears to be an in-memory structure built only from messages exchanged in the current live shell PTY. When a session is reopened (after sleep/wake, app restart, or simply navigating away and back — see the LocalSessions.startShellPty event for an existing session ID), the chain resets to the latest 1–2 turns rather than being rehydrated from the persisted JSONL. All earlier messages then fail validation as "not on active chain", even though they exist in storage.

This would also explain the constant chain size of 2 regardless of N, and why Edit/Write sessions are unaffected (file-history events presumably force a rehydrate path that conversation-only sessions skip).

Reliable reproduction of the regression:

1. Start a new session and exchange several messages (rewind works for any of them).
2. Close the session tab / quit Desktop / let the laptop sleep.
3. Reopen the same session.
4. Rewind to any prior message → fails with chain size 1/N or 2/N.

Log signature: a LocalSessions.startShellPty: sessionId=<existing> event precedes the failing rewind attempts.

Happy to attach a minimal failing session JSONL + main.log excerpt if useful.

[ahgoos]

Adding a macOS data point that lines up with your updated PTY-rehydrate hypothesis.

Platform: macOS, Claude Desktop 1.7196.0 (also reproduced on 1.6608.0). Terminal Claude Code 2.1.139 on the same machine rewinds correctly against the same shared session jsonl files, isolating the regression to Desktop's LocalSessions.rewind path — same as your Windows isolation.

Log signatures match. ~/Library/Logs/Claude/main.log shows both variants on every failing attempt:

[Rewind] No rewind point for local_<sid> target=<uuid> (assistantUuid=none, hasText=true)
[Rewind] target=<uuid> → assistantUuid=<uuid> not on active chain for local_<sid> (chain size 5/1367)

LocalSessions.startShellPty is reliably present as a precursor. On long-lived sessions that have been reopened many times across sleep/wake and app restarts, the same sessionId produces a stream of startShellPty events, and rewind attempts between those events all fail with single-digit N against a large M.

N is not strictly constant at 2, but it is uniformly tiny. Observed values across distinct sessions: 1/678, 3/471, 4/402, 4/451, 5/1367, 8/466. Consistent with "in-memory chain = current PTY's exchange only" if the user happened to send a few more turns since the latest PTY restart before attempting rewind.

On-disk jsonl is structurally sound — directly supporting the "in-memory chain diverges from persisted chain" framing. For one failing session I walked the jsonl: 964 lines, 772 entries with UUIDs, 771 parentUuid refs, 0 orphan refs. Walking parentUuid from the latest leaf reaches 763 of 772 entries — i.e. essentially the whole file is on the persisted chain. Desktop's log for that same sessionId reported chain size 5/1367. So the in-memory chain is both shorter than (5 vs 763) and larger in total than (1367 vs 772) the persisted jsonl, which would be expected if PTY-restart accumulates duplicate in-memory entries without rehydrating ancestry.

Possible additional trigger (not required, but observed): the failing jsonl mixes entrypoint=claude-desktop entries from versions 2.1.121 and 2.1.128, consistent with a session that survived a Desktop auto-update mid-conversation. Your conversation-only / brand-new-session repro shows PTY-restart alone is sufficient; mid-session version mix may be a second path into the same broken state.

Happy to attach a sanitized log excerpt showing the startShellPty → failing rewind sequence if useful. (I filed #60121 with the macOS-side detail before finding this issue — happy to close #60121 as a duplicate of this one once a maintainer confirms.)

[pudDesign]

Cross-posting the proposed fix from #60121 here before it auto-closes as a duplicate of this issue (per the github-actions bot, in ~3 days). Full credit to @jshaofa-ui:

Proposed Solution

Root Cause

Desktop's in-memory chain reconstruction diverges from the persisted parentUuid graph when sessions span multiple Desktop client versions (mid-session auto-update). The in-memory chain collapses to single-digit length while the disk chain has hundreds of entries.

Fix 1: Fall back to on-disk parentUuid chain when in-memory chain is too short

async rewind(sessionId: string, targetUuid: string): Promise<RewindResult> {
  const inMemoryChain = this.getMemoryChain(sessionId);
  if (inMemoryChain.size < inMemoryChain.totalEntries * 0.5) {
    const diskChain = await this.buildChainFromDisk(sessionId);
    if (diskChain.has(targetUuid)) {
      return this.truncateToUuid(sessionId, targetUuid, diskChain);
    }
  }
  // Original in-memory path...
}

Fix 2: Fix chain reconstruction for multi-version sessions

Include ALL entries regardless of entrypoint or version metadata. The current filter incorrectly excludes cross-version entries.

Fix 3: Add diagnostic logging

When chain reconstruction produces a suspiciously short chain, log a warning and fall back to disk chain.

Impact

• Severity: Critical. Completely breaks rewind for affected sessions
• Users Affected: All users with multi-version sessions (very common)
• Fix Complexity: Medium. Chain reconstruction logic needs adjustment
• Risk: Low. Fallback to disk chain is safe; disk JSONL is authoritative

Full solution: solutions/claude-code-60121-cant-rewind-plugin-independent-fix.md

Supporting Fix 1 (the disk fallback) specifically: the cases my report covers (brand-new conversation-only sessions, session-reopen via LocalSessions.startShellPty) involve chains that collapse to 1 or 2 entries without any multi-version mixing, so Fix 2 alone wouldn't catch them; Fix 1 would. @ahgoos's analysis above (walking parentUuid reaches 763/772 entries on a session Desktop reported as 5/1367) further supports treating the persisted JSONL chain as authoritative when the in-memory chain has collapsed.