[Bug] ZCode 3.5.2 host crashes on startup — RangeError: Failed to allocate memory (ERR_MEMORY_ALLOCATION_FAILED) in bundled Node 24.14.0 on Brotli response; chat & workspaces blank

[GeneGulanesJr]

中文摘要： ZCode 3.5.2（AppImage）启动约 1 秒后宿主进程 zcode-host-local-1 崩溃，聊天不可用、所有工作区面板空白。崩溃发生在宿主进程首次收到 Brotli（content-encoding: br）压缩的 HTTPS 响应、Node 构造 BrotliDecompress 解压器时，抛出 RangeError: Failed to allocate memory（ERR_MEMORY_ALLOCATION_FAILED）。这是 AppImage 内置 Node 24.14.0 的问题（非真实内存不足——崩溃时系统剩余 25 GB），系统 Node 26.4.0 的子进程 zcode-agent 正常。

---

Severity

Blocker — app is unusable; crashes within ~1s of startup on every launch.

Environment

• OS: CachyOS (Arch-derived), Linux x86_64
• ZCode: 3.5.2 — ZCode-3.5.2-linux-x64_2bbb086c310b2e58912ffc11a7780df6.AppImage
• Install method: Manual AppImage download (auto-update disabled)
• System Node: v26.4.0 (used by the zcode-agent child process)
• Bundled host Node: v24.14.0 (the Electron host runtime inside the AppImage)
• RAM: 32 GB total / 25 GB free at time of crash → not an OOM

Symptoms

• Host process zcode-host-local-1 dies immediately after startup.
• Chat is unusable; all workspace/conversation panels render blank.
• Repeats on every launch; app never reaches a working state.
• First observed 2026-07-24 23:16, persists through 2026-07-25.

Root cause (fatal stack)

The host throws an unhandled 'error' event the first time it receives a Brotli-encoded (content-encoding: br) HTTP response. The failure happens while constructing the Brotli decompressor:

node:events:486
      throw er; // Unhandled 'error' event
      ^

RangeError: Failed to allocate memory
    at createUnsafeBuffer (node:internal/buffer:1095:25)
    at allocate (node:buffer:472:10)
    at Buffer.allocUnsafe (node:buffer:435:10)
    at BrotliDecompress.ZlibBase (node:zlib:264:28)
    at BrotliDecompress.Brotli (node:zlib:839:12)
    at new BrotliDecompress (node:zlib:857:10)
    at Object.value [as createBrotliDecompress] (node:zlib:944:14)
    at Object.onHeaders (node:internal/deps/undici/undici:12902:40)
    at Request.onHeaders (node:internal/deps/undici/undici:2969:33)
    at Parser.onHeadersComplete (node:internal/deps/undici/undici:7426:31)
Emitted 'error' event on Readable instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    ...
  code: 'ERR_MEMORY_ALLOCATION_FAILED'

Node.js v24.14.0
host process (local-1) exited with code 1

Main-process log then reports:

[crash-capture] child-process-gone: { type: 'Utility', reason: 'abnormal-exit',
  exitCode: 256, serviceName: 'node.mojom.NodeService', name: 'zcode-host-local-1' }

(and occasionally exitCode: 134 / reason: 'crashed' → SIGABRT).

Why this is a Node 24 bug, not a real OOM

• Allocation fails at createUnsafeBuffer while instantiating a BrotliDecompress stream from response headers — a tiny, bounded allocation. With 25 GB free, a genuine OOM is impossible here.
• The ERR_MEMORY_ALLOCATION_FAILED originating in node:zlib + node:internal/deps/undici onHeaders is a known failure shape in Node 24.x where decompressor creation throws spuriously.
• The same machine runs system Node 26.4.0 for the zcode-agent child without issue; only the host on bundled Node 24.14.0 crashes.

Reproduction

1. Launch ZCode 3.5.2 AppImage on a CachyOS/Arch x86_64 machine.
2. Host starts, initializes conversations (zcode-agent.initializeConversationV4 OK, setting.get OK, model-provider.getProviderRegistrySnapshot OK).
3. Host makes its first HTTPS call returning a Brotli-compressed body (provider registry / zcode.z.ai).
4. Crash. Panels never populate.

Diagnostic notes

• ~/.zcode/v2/tasks-index.sqlite → PRAGMA integrity_check; returns ok (data is intact, just never loaded).
• ~/.zcode/v2/setting.json and credentials.json are valid JSON.
• No file corruption, no large files, no .tmp write leftovers.
• Minidumps present at ~/.zcode/v2/crash/live/pending/*.dmp.

Suggested fix

Bundle Node 22 LTS (or 26) in the host runtime instead of 24.14.0. As a stopgap:

• Request responses with Accept-Encoding: gzip (or identity) so the Brotli path is avoided, and/or
• Attach an 'error' handler on the decompression stream so a single bad response doesn't kill the host process.

Happy to provide the minidumps or full logs if useful.

[github-actions]

👋 感谢你的反馈，我们已经收到。

• 维护者会在 3 个工作日内 给出首次响应。
• 状态保持为 status: 待评估，你可以随时补充信息。
• 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

---

👋 Thanks — we've received your issue.

• A maintainer will respond within 3 business days.
• Status stays at status: 待评估 (Triage); feel free to add context.
• If we need more details, we'll add needs: 更多信息 and ping you.

[GeneGulanesJr]

Update 2 — actual root cause found (please disregard the Node-24-bug and kernel theories above). I want to correct the record clearly since my earlier analysis pointed in the wrong direction.

What actually happened

The crash was triggered by the agent reading large binary files into the host process, exhausting the V8 heap. It is not a Node 24 bug, not an OOM, and not kernel-related — those were red herrings I chased because I didn't initially trust the on-the-ground context.

Evidence

• ZCode worked perfectly Jul 12 → Jul 24 ~00:03 (12 days of logs, zero crashes, conversations loading with 287+ messages).
• Jul 24 15:07: a task was created asking ZCode to investigate turning Genetec CCTV recordings (.dar files) into MP4. To identify the codec, the agent read the raw .dar files (parsing H.264 NAL headers like 00 00 01 67).
• Those .dar files are large: 233 MB and 236 MB each (20260612_15.dar, 20260612_16.dar).
• Jul 24 23:10:39: first RangeError: Failed to allocate memory, on a host that had been running fine all day, the moment the user returned to that conversation. From then on, every launch crashes within ~1s.

Why "Failed to allocate memory" is misleading here

The host process is Node 24.x with a bounded V8 heap. When the agent read a 233 MB binary file, the buffered tool-result payload blew the V8 heap. Once the heap is exhausted/corrupted, every subsequent Buffer.allocUnsafe / allocUnsafeSlow throws ERR_MEMORY_ALLOCATION_FAILED — even tiny allocations like writing settings or constructing a Brotli decompressor. The error message sounds like system OOM, but the machine had 25 GB free the whole time. It's V8 heap exhaustion from buffering a giant binary, not a memory shortage.

Why every relaunch kept crashing

The poisoned conversation stayed in the task store, and the host reloaded it (and its oversized cached content) on startup → instant re-exhaustion → crash loop. Deleting that one task broke the loop.

The ask / suggestion

The agent should never buffer whole large binary files into the host heap. Concretely:

1. Stream + truncate tool outputs that return binary or very large content (cap at e.g. 1–5 MB, with a "truncated, N bytes total" marker).
2. For file-read tools, detect binary (NUL bytes / non-UTF-8) and either refuse with a clear message or return metadata (size, magic bytes, codec hint) instead of raw bytes.
3. Attach 'error' handlers on the streams so a single oversized payload degrades gracefully instead of killing the host with an unhandled 'error' event.

Cleanup notes (for anyone hitting this)

• The trigger was a folder of 27 GB of CCTV exports sitting inside a ZCode-opened workspace. Moving binary-media folders out of the workspace prevents re-trigger.
• A single UPDATE tasks SET deleted=1 WHERE task_id=... on tasks-index.sqlite (ZCode closed) broke the crash loop for me; all other history was preserved.

Sorry for the noise in the earlier comments — hope the corrected diagnosis helps. Happy to provide the full task content / logs if useful.