[BUG] Claude Code desktop 2.1.181 (Windows 11) — session truncated, recovers neither from reload nor from clean restart

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?

Claude Code desktop renders a truncated view of a long-running chat session. The conversation visibly ends mid-stream, with the assistant bubble empty after a tool-result. View → Reload does not recover the missing turns. Full app quit + relaunch does not recover them either.

The underlying session .jsonl on disk (~/.claude/projects/<project>/<session-id>.jsonl) contains the full conversation — hundreds of additional turns past where the UI cuts off. So this is a render/cache issue, not data loss.

Scope on my machine: ~63 of ~651 session files (~10%) show a pattern where the final last-prompt record's leafUuid points to a node well before the actual conversation tail.

Concrete example: session c29297db-bad2-4297-97d2-a0c38fd96463 in cdt-app. File has 1,533 lines and the chain extends to a final assistant message at line 1,531 with timestamp 2026-06-22T00:54:58Z. The desktop renders only through ~line 1,255 and then shows an empty assistant bubble.

Diagnostic attempted: I wrote a script to append a new last-prompt record on each affected file with leafUuid set to the actual last-assistant uuid, then fully quit and relaunched the desktop. Zero effect on what was rendered. That tells me the renderer is not sourcing the visible tail from last-prompt.leafUuid — it's reading from somewhere else, probably Electron LocalStorage/IndexedDB (~/AppData/Roaming/Claude/Local Storage/leveldb, ~42 MB, actively written) or possibly a server-side cache. Cleared/moved-aside Local Storage as a second attempt; no change.

What Should Happen?

The full conversation that exists on disk in the session jsonl should be rendered, with no silent truncation. At minimum:

1. Document where the renderer sources the visible conversation tail (jsonl on disk vs IndexedDB vs server) so users can self-recover.
2. Provide an in-app "rebuild this session from disk" / cache-invalidation action for an individual conversation.
3. Investigate why last-prompt.leafUuid falls behind the actual file tail in ~10% of sessions, and whichever subsystem actually drives rendering, surface a warning when it falls behind the jsonl.

Error Messages/Logs

Steps to Reproduce

I cannot give a clean minimal repro — the bug appears spontaneously in long, tool-heavy sessions and persists after every recovery action I tried. Pattern that correlates on my machine:

1. Long-running session (mine was ~1,500 jsonl lines, many tool calls, mixed claude-opus-4-7 and claude-opus-4-8 entries, several /pickup and /acclimate skill invocations).
2. At some point during a heavily streamed assistant turn the bookmark stops advancing. Subsequent turns keep appending to disk normally.
3. On any later relaunch the session renders truncated at the stuck point.

Diagnostic data I can supply on request:

• Sanitized copy of the affected jsonl (1.5 MB)
• Script that finds these stuck sessions across ~/.claude/projects (61/651 hits on my machine)
• Tree of parent/child uuids around the cutoff

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.181

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

The fact that quitting the desktop completely and moving aside Local Storage/IndexedDB still did not invalidate the truncated view suggests the truncation may be cached server-side (or the desktop has yet another local cache layer I didn't find). If a maintainer can confirm where conversation rendering reads from, I can run further diagnostics.

Happy to share session-id-level data privately if useful.