Crash on session resume: undefined is not an object (evaluating 'H.startsWith') in Edit result renderer
Bug Description
When resuming a previously closed conversation session (selecting it from the session list and pressing Enter), Claude Code crashes with:
ERROR undefined is not an object (evaluating 'H.startsWith')
The session was working normally before being closed. The crash occurs immediately on resume, before any interaction.
Stack Trace
DR7 (/$bunfs/root/src/entrypoints/cli.js:1772:487)
Ce7 (/$bunfs/root/src/entrypoints/cli.js:2929:18047)
_w (/$bunfs/root/src/entrypoints/cli.js:453:20997)
$O (/$bunfs/root/src/entrypoints/cli.js:453:39538)
Ks (/$bunfs/root/src/entrypoints/cli.js:453:50229)
sEH (/$bunfs/root/src/entrypoints/cli.js:453:86903)
M0 (/$bunfs/root/src/entrypoints/cli.js:453:85865)
aEH (/$bunfs/root/src/entrypoints/cli.js:453:85687)
WDH (/$bunfs/root/src/entrypoints/cli.js:453:82433)
FH (/$bunfs/root/src/entrypoints/cli.js:453:6488)
Root Cause Analysis
The crash is in the DR7 function which renders Edit tool structured results:
function DR7({filePath:H, structuredPatch:_, originalFile:q}, $, {style:K, verbose:O}) {
let T = H.startsWith(PT()); // <-- crashes here, H is undefined
...
}
Unlike YR7 (which guards with if(!H) return null) and vV_ (which uses optional chaining H.file_path?.startsWith), DR7 does not null-check filePath before calling .startsWith().
Thorough data analysis of the session file (1633 lines, 152 Edit/Write tool calls, plus subagent files including compact) found zero malformed entries — all file_path values are valid strings, all tool_use/tool_result pairs are matched, no orphaned entries, no structural anomalies. This suggests the issue is in how the renderer reconstructs/receives props during session reload, not in the persisted data.
Suggested Fix
Add a null guard in DR7, consistent with the pattern used in YR7:
function DR7({filePath:H, structuredPatch:_, originalFile:q}, $, {style:K, verbose:O}) {
if (!H) return null; // Add this guard
let T = H.startsWith(PT());
...
}
Environment
- Claude Code version: 2.1.87
- OS: macOS Darwin 25.2.0 (arm64)
- Runtime: Bun (per
/$bunfs/root/path prefix)
Session Characteristics
The affected session is a large, long-running conversation with:
- 1633 JSONL entries in main session file (5.4MB)
- 152 Edit/Write tool_use entries (all with valid
file_pathstrings) - 12+ subagent files including a 1.9MB compact subagent
- Multiple cross-repository Edit operations (editing files in ~8 different repo directories)
- Context compaction was triggered during the session
Steps to Reproduce
- Have a long conversation session with many Edit/Write tool calls across multiple repositories
- Close the session normally
- Restart Claude Code and select the session to resume
- Crash occurs immediately during conversation render
Workaround
No known workaround yet — the session data appears valid but the renderer crashes during reload.
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Update: Root Cause Identified via Binary Search
Through a binary search on the session's 1633 JSONL entries, we identified the exact line that triggers the crash.
Root Cause
The crash occurs when the conversation renderer encounters a successful Edit tool result (non-error) that contains only a plain text
contentstring (e.g.,"The file ... has been updated successfully.") withoutstructuredContent.The
DR7function is called to render the diff view for this successful Edit result, but receivesundefinedforfilePathbecause the result data doesn't include structured fields (filePath,structuredPatch,originalFile) that the renderer expects.The failing Edit results look like this:
The corresponding tool_use looks normal:
Key Observation
Earlier successful Edit results in the same session (e.g., around line 96) with the identical format do NOT crash. The difference is context-dependent:
is_error: true("File has not been read yet"), and only the 5th succeeded.DR7) lacks a null guard onfilePath.DR7.How We Found It
file_path/filePathvalues. Found nothing — all stored data is structurally valid.Workaround
We fixed the session file by converting all 93 successful Edit results to error format:
This prevents the diff renderer (
DR7) from being invoked, and the session now loads successfully.For other users hitting this error: Back up your session file (
.jsonl), then run a script to mark successful Edit tool results as errors. The conversation context is preserved and the session becomes resumable. See the follow-up comment for a complete copy-paste script.Suggested Fix
Add a null guard in
DR7, consistent with the pattern used inYR7:Additionally, the caller (
Ce7) should validate that the structured result data containsfilePathbefore dispatching toDR7, particularly for Edit results that only have plain textcontent(nostructuredContent).Not a duplicate — this issue provides the only known workaround
The flagged issues are indeed the same underlying bug:
replace_all: true+ emptynew_stringas a trigger, but no workaround beyond manually removing JSONL entries and repairing the parentUuid chainThis issue is the only one that provides a scriptable workaround that preserves the full conversation context and allows the session to resume:
Back up your session file first. Session files are in
~/.claude/projects/<project-hash>/<session-id>.jsonl.This also adds new findings to the root cause: the crash specifically triggers when a successful Edit result completes a full set of tool results for a multi-tool-use assistant turn, causing the renderer to switch from a partial/pending view to a full diff rendering view — which is where the missing null guard on
filePathinDR7causes the crash.Keeping this issue open so users searching for the workaround can find it.
same problem, and the fix script works.
Confirmed the workaround script works. Had the same crash on v2.1.85/2.1.87 with a large session (10620 lines, 275 Edit tool calls). The script from the second comment patched 269 successful Edit results and the session now resumes successfully. Thanks @tiffsequence for the thorough root cause analysis and fix!
Should be fixed in v2.1.99
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.