[BUG] claude --resume crashes with "Cannot read properties of null (reading 'split')" when session contains Edit results with originalFile: null

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 --resume crashes immediately on session render when the session contains Edit tool results where originalFile is null. The Windows desktop client exhibits the same crash silently — UI loads, then chat area, sidebar and input field all go gray. Only the CLI surfaces the actual error.

After analyzing the affected session JSONL (~3.3h session, multiple Edit calls across several files), the root cause is deterministic and correlates with file size, not with errors or interruptions:

• All Edit entries with originalFile != null had original file sizes between 340 bytes and 7,731 bytes.
• All Edit entries with originalFile: null were on substantially larger files (a single-file PHP web UI and a Python module, both well above 10 KB).
• The null entries are distributed across the entire session timeline — no clustering, no preceding errors, no interruptions.

This rules out "corrupted by a one-off API hiccup" and points to a normal Claude Code behavior: the writer appears to omit the original file content from the JSONL when the file exceeds some size threshold (presumably ~8–10 KB), writing null instead. This is fine for storage; the data itself is structurally valid.

The bug is in the resume code path, not the writer:

• Function MEq (cli.js:1892) calls .split() on originalFile without a null-check.
• For small-file Edits this works because originalFile is a string.
• For large-file Edits where originalFile: null is the legitimate written value, .split() throws and the entire session becomes unresumable.

This is the same class of bug as #40160 and #40452 (missing null guards in Edit-result renderer functions for filePath), but in a different function (MEq) and on a different field (originalFile instead of filePath).

What Should Happen?

claude --resume should gracefully handle Edit entries where originalFile is null, since null is a legitimate value the writer produces for large files.

Suggested Fix

A null-guard in MEq consistent with the pattern used in #40452 (which suggests if (!H) return null; in the analogous renderer function DR7) should resolve this. The exact placement is up to whoever owns this code path — I haven't seen the un-minified source.

Treating null as "" (or early-returning) has zero user-facing impact in this context, because the actual diff content is stored separately in structuredPatch, oldString, and newString.

Error Messages/Logs

ERROR  Cannot read properties of null (reading 'split')

file:///C:/Users/<user>/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:1892:575

- Object.MEq (cli.js:1892:575)
- t_K (cli.js:3049:17801)
- W$ (cli.js:527:20995)
- z2 (cli.js:527:39534)
- Ms (cli.js:527:50224)
- NS6 (cli.js:527:86896)
- nZ (cli.js:527:85858)
- VS6 (cli.js:527:85681)
- fJ6 (cli.js:527:82426)
- m6 (cli.js:527:6359)

Steps to Reproduce

1. Start a Claude Code session.
2. Use the Edit tool on a file larger than ~10 KB (the exact threshold I haven't measured — anything clearly above 10 KB triggers it reliably).
3. End the session normally.
4. Run claude --resume and select that session.
5. Crash on render.

Workaround: Patch the JSONL — in the affected session file under ~/.claude/projects/<project>/<session>.jsonl, replace "originalFile": null with "originalFile": "" on the affected lines. The session resumes cleanly afterwards.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.87 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Diagnosis was performed collaboratively with Claude (claude.ai web client) in a separate session. The JSONL analysis (line numbers, file size correlation, distribution across the timeline) was done by Claude Code itself running locally on the affected session file.
I have full diagnostic output from both sessions and am happy to share excerpts if useful.