Crash on conversation resume: H.indexOf is not a function in isResultTruncated

Status Fixed / completed
Maintainer reply ✓ Yes — ashwin-ant
Activity 3 comments · opened Apr 3, 2026 · closed Apr 18, 2026
💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

Bug

Resuming a conversation crashes with:

ERROR  H.indexOf is not a function. (In 'H.indexOf(`
        `,_)', 'H.indexOf' is undefined)

Stack trace

Hb (/$bunfs/root/src/entrypoints/cli.js:1518:65)
isResultTruncated (/$bunfs/root/src/entrypoints/cli.js:1540:4784)
<anonymous> (/$bunfs/root/src/entrypoints/cli.js:5959:15701)
<anonymous> (/$bunfs/root/src/entrypoints/cli.js:5959:7779)
map (native:1:11)
QW7 (/$bunfs/root/src/entrypoints/cli.js:5959:7735)
fO (/$bunfs/root/src/entrypoints/cli.js:480:20983)
qA (/$bunfs/root/src/entrypoints/cli.js:480:39521)
Gk (/$bunfs/root/src/entrypoints/cli.js:480:50210)
EDH (/$bunfs/root/src/entrypoints/cli.js:480:86865)

Analysis

isResultTruncated calls .indexOf("\n") on a value (H) that is undefined instead of a string. This likely happens when a tool result in the persisted conversation has a null/undefined content field that isn't guarded before the string method call.

Reproduction

  1. Have a conversation with tool calls
  2. Exit
  3. Resume with claude --resume
  4. Crash occurs during conversation restoration

Environment

  • Platform: macOS (Darwin 24.6.0)
  • Runtime: Bun

View original on GitHub ↗

3 Comments

cstripling-brex · 6 months ago

Update: Root cause narrowed down

The crash is not caused by null content fields in messages, system messages, or file-history-snapshots. I patched all of those and the crash persisted.

The crash is specifically triggered by tool_use/tool_result block structures during conversation rendering on resume.

What I tried (didn't fix the crash):

  1. Patching null text fields in tool_reference items inside tool_result arrays → still crashed
  2. Fixing 18 system messages with null content → still crashed
  3. Fixing 13 null backupFileName values in file-history-snapshot entries → still crashed
  4. Converting array-type tool_result content to strings while keeping block type as tool_result → still crashed

What fixed it:

Converting all tool_use and tool_result blocks to text blocks (e.g., [Used tool: Read with input: {...}] / [Tool result: ...]) and dropping file-history-snapshot entries. This preserves conversation context while avoiding the renderer crash.

Conclusion:

The isResultTruncated function (or something in its call chain via the .map() in QW7) crashes when processing tool_use/tool_result block types during re-rendering, not due to null values but likely due to the block structure itself. The conversation had MCP tool results (Datadog, Glean, Linear) which may have non-standard content shapes the renderer doesn't handle.

Workaround for others:

# Convert tool blocks to text summaries in a conversation JSONL:
cd ~/.claude/projects/<your-project>
cp <session-id>.jsonl <session-id>.jsonl.bak
jq -c '
  if .type == "file-history-snapshot" then empty
  elif .type == "assistant" and (.message.content | type) == "array" then
    .message.content = [.message.content[] |
      if .type == "tool_use" then
        {type: "text", text: ("[Used tool: " + .name + " with input: " + (.input | tostring | .[:500]) + "]")}
      else . end]
  elif .type == "user" and (.message.content | type) == "array" then
    .message.content = [.message.content[] |
      if .type == "tool_result" then
        {type: "text", text: (if (.content | type) == "string" then "[Tool result: " + (.content[:1000]) + "]"
          elif (.content | type) == "array" then "[Tool result: " + ([.content[] | .text // .tool_name // ""] | join(" ") | .[:1000]) + "]"
          else "[Tool result: empty]" end)}
      else . end] |
    if (.message.content | length) == 0 then empty else . end
  else . end
' <session-id>.jsonl.bak > <session-id>.jsonl
ashwin-ant collaborator · 6 months ago

This was fixed in v2.1.97 — Resuming a conversation with array-shaped MCP tool results no longer crashes with 'H.indexOf is not a function'. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

github-actions[bot] · 5 months ago

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.