Desktop (macOS): renderer V8 OOM crash loop when pasting large JSON into composer (parsePromptInputV2Editor) #43935

Activity

1. github-actions

   assigned

   Hona

   on Aug 21, 2026
2. github-actions commented on Aug 21, 2026

   

   github-actionsBot

   on Aug 21, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Possible Bug: Renderer OOM crash loop after updating to v1.17.18 #36218: Renderer OOM crash loop on relaunch — same pattern of persisted data being re-parsed on boot, causing an unbootable crash loop
   • V8 OOM Crash on Linux - Renderer Process Exits with Code 4 #39055: V8 OOM crash (renderer process gone, exitCode 4/5) on startup — similar V8 heap exhaustion symptoms
   • OpenCode desktop v1.18.10 - V8 OOM 'Zone Allocation failed' when opening project #39825: V8 OOM on startup, server and renderer both OOMing, macOS — same platform and similar persistence-triggered crash

   If your issue is specifically about the paste input size triggering the OOM (rather than session history size), it may be a distinct root cause worth tracking separately — please let a maintainer know if so.
3. Pilotx1992 commented on Sep 15, 2026

   

   Pilotx1992

   on Sep 15, 2026

   More actions

   I can reproduce a closely related issue on Windows with OpenCode Desktop 1.18.31, and I have a full debug bundle containing multiple renderer-unresponsive samples.

   Environment

   • OpenCode Desktop: 1.18.31
   • OS: Windows x64
   • Electron: 42.3.3
   • Chrome: 148
   • Node: 24.15

   What happens

   When I paste a large technical prompt, report, or log directly into the OpenCode Desktop composer, the UI can become completely unresponsive.

   This is a renderer/UI hang rather than a normal delay waiting for the model/provider.

   My debug bundle contains multiple renderer unresponsive events. The captured stacks repeatedly point to the same prompt-editor path:

   HTMLDivElement.onPaste
   → PromptInputV2
   → parsePromptInputV2Editor
   → editor/node traversal
   → input/state updates
   

   Other samples during the same type of freeze include:

   onPaste
   → input processing
   → setPrompt
   → JSON.stringify
   → reactive updates
   

   The important point is that my Windows logs independently converge on the same parsePromptInputV2Editor / onPaste area reported in this issue.

   Observed timestamps

   The debug logs contain several renderer-unresponsive events, including approximately:

   19:33:05  renderer unresponsive
   19:47:13  renderer unresponsive
   20:23:06  renderer unresponsive
   00:39:06  renderer unresponsive
   

   The last freeze occurred immediately before I exported the debug package.

   ResizeObserver activity

   The renderer logs also contain a very large number of:

   ResizeObserver loop completed with undelivered notifications.
   

   messages during affected sessions.

   I cannot prove that ResizeObserver activity is the root cause, but there appears to be significant layout/reactive churn around the same Desktop renderer sessions.

   Important distinction: hang vs crash

   In my case I do not currently see evidence that the whole Desktop application process crashes.

   The behavior is primarily:

   renderer hang / UI freeze
   

   rather than:

   full process crash
   

   The backend/agent can remain alive while the Desktop UI is unresponsive.

   Additional system-pressure finding

   The same debug package also captured a separate Windows subprocess failure:

   0xC000012D
   STATUS_COMMITMENT_LIMIT
   

   followed shortly afterward by:

   0xC0000142
   STATUS_DLL_INIT_FAILED
   

   So the machine also experienced Windows virtual-memory pressure during a long-running development workload.

   I consider that a secondary issue rather than the primary cause of the paste-specific renderer hangs, because the renderer stacks repeatedly identify the paste/editor path.

   Expected behavior

   Large pasted input should not be able to synchronously block the Electron renderer.

   Potential mitigations could include:

   • moving expensive paste parsing/normalization off the renderer main thread where possible;
   • chunking/yielding during large input processing;
   • avoiding repeated whole-editor traversal or serialization;
   • limiting unnecessary reactive/layout work;
   • applying a safe large-paste threshold;
   • warning the user when unusually large input is pasted;
   • storing large pasted blocks in a more compact representation rather than continuously rendering/parsing the entire payload.

   Reproduction pattern

   1. Open an existing OpenCode Desktop development session.
   2. Copy a large technical prompt, log, audit report, or structured specification.
   3. Paste it directly into the composer.
   4. The UI becomes very slow or Windows reports the application as not responding.
   5. It may eventually recover without a full process crash.

   I have the complete opencode-debug-20260914T213910.zip bundle containing the window, renderer, server, network, and related logs.

   I can provide a sanitized copy of the bundle if it would help investigation.

   I would be happy to provide additional reproduction data, prompt sizes, or another debug capture if needed.
4. marketlab-agence commented on Sep 25, 2026

   

   marketlab-agence

   on Sep 25, 2026

   More actions

   Additional data point: Windows 11 + Desktop 1.18.32 — here the paste path produces a hard renderer OOM crash, not only a hang.

   Environment

   • OpenCode Desktop 1.18.32, Windows 11 x64
   • Renderer reaches the V8 heap ceiling and is killed.

   Evidence — %APPDATA%\ai.opencode.desktop\logs\<run>\window.log

   [2026-09-25 05:16:55] (window) renderer unresponsive
   [2026-09-25 05:17:16] (window) app render process gone {
     url: 'oc://renderer/index.html',
     details: { reason: 'oom', exitCode: -536870904 }
   }
   

   Captured unresponsive samples converge on the same editor/paste path reported here:

   HTMLDivElement.onPaste → PromptInputV2._el$6.$$input → parsePromptInputV2Editor → visit/Array.from
   HTMLDivElement.onPaste → ... → setPrompt → setItem → encode → JSON.stringify
   

   Independent of session-history size (relevant to the first comment above)

   The user's opencode.db was 9.7 GB (dominated by a bloated event table). After archiving/trimming it to 1.85 GB (PRAGMA integrity_check = ok), the renderer still OOM'd on the next large paste. So at least in this case the trigger is the paste payload / editor serialization, not the session history — which supports treating the paste-size path as a distinct root cause.

   Aggravating factor

   Low free RAM (1.2 GB of 15.8 GB, due to several local MCP servers) plus a drafts.sqlite holding multi-MB attachment blobs. A large paste then tips the renderer over the V8 heap limit.

   Suggested mitigations

   • Cap / warn on very large pastes (safe paste threshold).
   • Parse and store large pasted blocks off the renderer main thread and/or in a compact representation.
   • Chunk / yield during input processing; avoid repeated whole-editor traversal.
   • Avoid whole-editor JSON.stringify on every input; avoid unnecessary reactive/layout work.

   Related: #46392 (large HTML paste → renderer OOM-killed). I can provide a sanitized window.log if useful.
5. frontmesh commented on Oct 6, 2026

   

   frontmesh

   on Oct 6, 2026

   More actions

   I’m seeing a similar problem in OpenCode Desktop. Pasting a large JSON payload into the prompt makes the app hang, followed by an alert asking me to relaunch the desktop app.

   The payload is valid JSON containing 69 log entries: 202,777 bytes (about 203 KB), 5,342 lines. This happens when pasting into the prompt input.

   I haven’t confirmed an out-of-memory error from diagnostic logs, but the visible symptoms are a hang followed by the relaunch alert.
6. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
7. thdxr

   closed this as not plannedon Oct 11, 2026