fix: sidecar crashes (SIGTRAP) when apply_patch deletes a large/binary file

[wangzexi]

Description

When apply_patch processes a delete operation on a large or binary file (e.g. a 142 MB .dmg), it calls createTwoFilesPatch(filePath, filePath, entireFileContent, "") to build a unified diff. For a 142 MB binary file this produces a diff string of ~380 MB. That string is stored verbatim in the SQLite part.data column.

On the next query that runs StatementSync.all() over that session's parts, Node's built-in sqlite module passes the 380 MB char* to v8::String::NewFromUtf8. V8 has an internal string-length assertion (~512 MB limit) and hits it as a SIGTRAP / EXC_BREAKPOINT, bringing the entire sidecar process down.

The same risk exists in edit.ts's trimDiff function, which is called from all edit/patch paths and does no size check before splitting the diff on newlines.

Crash stack from macOS crash report:

v8::String::NewFromUtf8
node::sqlite::StatementExecutionHelper::ColumnToValue
node::sqlite::ExtractRowValues
node::sqlite::StatementExecutionHelper::All
node::sqlite::StatementSync::All

Steps to reproduce

1. Start opencode on macOS.
2. Ask the AI to delete a binary file >= ~50 MB (e.g. a .dmg, .iso, or large .zip) via apply_patch.
3. The sidecar process crashes with SIGTRAP / EXC_BREAKPOINT immediately after the patch is applied. All in-flight sessions are lost.

OS

macOS 15 (Darwin arm64)

OpenCode version

Latest dev branch (reproduced on current dev HEAD)

Root cause

apply_patch.ts (delete case): no size guard before calling createTwoFilesPatch + storing the result in SQLite.

edit.ts (trimDiff): no early return for strings that already exceed a safe size threshold, so even if the caller skipped the DB write, downstream processing would still allocate a multi-hundred-MB string.

[wangzexi]

The current PR (#27658) fixes the crash with a size-based guard (skip diff if content > 512 KB). This is minimal and safe to merge, but there is a more principled approach worth considering as a follow-up.

Root distinction: binary vs large text

The real problem is that binary files (images, archives, executables) should never be diffed at all — a unified diff of binary content is meaningless and can be arbitrarily large. Large text files, on the other hand, still have meaningful diffs; we just shouldn't store the full thing.

A cleaner solution would be:

function isBinary(content: string): boolean {
  return content.includes('\0') // null byte is the standard binary heuristic
}

function safeDiff(oldContent: string, newContent: string, filePath: string): string {
  if (isBinary(oldContent) || isBinary(newContent)) return ""

  const diff = createTwoFilesPatch(filePath, filePath, oldContent, newContent)
  const MAX_LINES = 500
  const lines = diff.split('\n')
  if (lines.length <= MAX_LINES) return diff
  return lines.slice(0, MAX_LINES).join('\n') + `\n... (${lines.length - MAX_LINES} more lines)`
}

This approach:

• Skips diff generation entirely for binary files (before calling createTwoFilesPatch, so no wasted CPU/memory)
• Preserves partial diffs for large text files instead of discarding them completely
• Applies consistently across all call sites in edit.ts and apply_patch.ts

The trade-off is a slightly larger diff (~30–40 lines touching all call sites) vs the current PR (~9 lines). Happy to leave this to maintainer judgment — the crash fix in #27658 is the priority.