Sessions created in older Claude Code versions silently fail to load (UI shows 'No messages yet') after upgrade

Summary

A long-running session created in an older Claude Code version (2.1.149) fails to display its conversation history after upgrading to a newer version (2.1.170). The session appears in the sidebar Recents list with a fallback name (derived from the first user message rather than the persisted ai-title), but opening it shows "No messages yet" — even though the JSONL file on disk is fully intact and contains a 3-week-long conversation.

Reproduction

1. Have a session that was created in Claude Code 2.1.149 (timestamp on first user message: 2026-05-24)
2. Upgrade Claude Code to 2.1.170 at some point
3. Restart Claude Code after the upgrade (in my case, to run a command that required releasing file handles)
4. Open the session from the Recents sidebar

Expected: Full conversation history loads as normal.
Actual: Session opens to "No messages yet" empty state.

Confirming the JSONL is intact

The session's JSONL on disk at ~/.claude/projects/<project-slug>/<session-id>.jsonl:

• 5,006,330 bytes (~5 MB)
• 1,157 lines, no parse errors
• Type distribution:
• assistant: 441
• user: 229
• ai-title: 129
• queue-operation: 112
• last-prompt: 91
• mode: 75
• attachment: 41
• system: 39
• File structure (set of types, field shapes per line) is identical to a session created in 2.1.170 — verified by diffing the type set against a current-version JSONL in another project. No corruption, no parse errors.
• The ai-title is set ("Discuss technical challenges and brainstorm solutions"), but the UI Recents item shows a fallback name derived from the first user message instead — suggesting the UI is opening the file, falling through whatever it uses to find the title in the new format, and concluding "no displayable content."

What I think is happening

Between 2.1.149 and 2.1.170, something changed about how the desktop UI resolves a JSONL into a displayable session — possibly the field path it uses to extract the conversation, or a stricter parser that rejects something the older version wrote. The session shows up because the directory scan finds the file; it fails to render because the parser can't extract the message stream.

Impact

For long-running primary working threads (mine spanned ~3 weeks of cross-project work), this is silent data loss from the user's POV. The file is there, but the user can't see it. There's no error toast, no warning, no migration prompt.

Workaround

I recovered my session content with a small Python script that parses the JSONL, flattens content blocks (text/tool_use/tool_result/thinking), and emits a readable Markdown transcript. The 511 substantive turns (user + assistant) extracted cleanly. So the data is recoverable — but only if you know to look for it on disk.

Suggestions

• If 2.1.170 detects a session it can't fully load, show an error ("This session was created in an older version and can't be displayed. File preserved at: …") rather than silently rendering "No messages yet."
• Consider a one-time migration pass on first run after upgrade.
• Surface the recovered file path so users don't lose work to a UI regression.

Environment

• Claude Code 2.1.170 (Windows desktop, "claude-desktop" entrypoint)
• Session created in 2.1.149
• Windows 11, Git Bash + PowerShell tooling
• Session was active and updated immediately before the restart that broke it (UI restart was triggered by needing to release MCP-server file handles for a file move — unrelated to this bug)

Happy to share the JSONL structure / file directly if useful (privately, since the content is personal).