Crash on resume: null.split() in Edit tool renderer when file-history-snapshot is missing

Bug Description

Resuming a conversation (claude --resume) crashes with null is not an object (evaluating 'q.split') when the conversation contains Edit tool results that have no associated file-history-snapshot entry in the JSONL.

Version

• Claude Code: 2.1.83 (Cask, macOS arm64)
• Original conversation created on: 2.1.71

Stack Trace

ERROR  null is not an object (evaluating 'q.split')

/$bunfs/root/src/entrypoints/cli.js:3163:2024

 - pl7 (cli.js:3163:2024)
 - cX7 (cli.js:2603:45367)
 - h9 → a1 → D7_ → nV_ → BQT → iV_ → X7_ → qT

Root Cause

The pl7 function (Edit tool success renderer) receives {filePath, structuredPatch, originalFile} and calls originalFile.split('\n') without a null guard:

// Deminified from cli.js:3163
function pl7({filePath, structuredPatch, originalFile}, K, {style, verbose}) {
    let R = filePath.startsWith(C5());
    return createElement(puT, {
        filePath,
        structuredPatch,
        firstLine: originalFile.split('\n')[0] ?? null,  // CRASH: originalFile is null
        fileContent: originalFile,
        style,
        verbose,
        previewHint: R ? "/plan to preview" : void 0
    });
}

The originalFile value is looked up from file-history-snapshot entries in the conversation JSONL, keyed by the assistant message's UUID. When no snapshot exists for a given message UUID, originalFile resolves to null.

Reproduction

1. Have a long-running conversation created on an older version (e.g. 2.1.71) that contains Edit tool calls
2. The conversation was forked/renamed (first line is a /rename system message, with forkedFrom pointing to another session)
3. Resume it on 2.1.83 with claude --resume
4. Crash occurs immediately during message rendering

In my case, 297 out of 328 Edit tool_use entries had no corresponding file-history-snapshot in the JSONL. The conversation had 26,668 lines and 18 subagents.

Suggested Fix

Add a null guard in pl7:

firstLine: (originalFile ?? "").split('\n')[0] ?? null,
fileContent: originalFile ?? "",

Or, more defensively, wherever originalFile is resolved from the snapshot store, fall back to "" instead of null.

Workaround

I was able to resume by patching the JSONL file directly — injecting file-history-snapshot entries (with current file contents from disk) for every assistant message UUID that was missing one. This prevents the null crash, though historical diffs may not render accurately.