claude --resume silently truncates session history at first malformed JSONL line

Summary

Claude Code's resume parser silently stops replaying a session's JSONL file at the first line it can't parse, treating everything after the malformed line as if it doesn't exist. The affected file on disk is fine (subsequent lines are valid JSON with real conversation content), but the user sees a resumed conversation that appears to "end" at an arbitrary point days earlier than the actual last message, with no warning, error, or indication that content has been skipped.

Reproduction

1. Run a long-lived Claude Code session over several days (~/.claude/projects/<proj>/<session-id>.jsonl grows to many MB).
2. At some point, one or more lines in the JSONL become malformed (in our case, an attachment of type queued_command and a file-history-snapshot — both metadata, not message content — appear truncated mid-JSON; suspected write-interruption or race during a queued-command save).
3. Later, run claude --resume <session-id> from the project directory.
4. The resumed session displays as if the conversation ended at the message just before the malformed line. The /resume picker shows an age consistent with that earlier timestamp, not the true last-activity timestamp.

Observed in our case

• Session file: 7,166 lines, real last activity 2026-04-18
• Malformed lines: L2636 (attachment: queued_command, 3809 chars, truncated at char 662) and L2655 (file-history-snapshot, 3146 chars, truncated at char 2145)
• On resume, Claude Code showed the conversation ending at L2629 (2026-04-10, "7d 15h old") — truncating ~4,500 lines / 11 MB of subsequent conversation including several merged PRs and major feature work
• After removing just those two malformed lines, the full history resumed correctly

Expected

One of:

• Skip malformed lines with a visible warning ([warning: 2 malformed lines in session file, continuing from next valid line])
• On resume, parse the full file tolerantly and show the last valid entry
• Detect truncated JSONL on write and self-repair, or at minimum validate newly-written lines before writing the next one

Actual

Silent truncation. User has no idea that content exists past the truncation point. The session looked abandoned 7 days ago when in fact it was actively used yesterday.

Environment

• Platform: Linux (Raspberry Pi, aarch64)
• Claude Code version: 2.1.114
• Session file size: ~17 MB when this was encountered

Impact

High for long-running sessions. Silent data loss from the user's perspective. Discovered only because the user remembered specific text from a later message and asked the assistant to search the raw file — otherwise the last ~11 MB of conversation history would have been effectively lost.