Windows Desktop renderer hangs on large paste in PromptInputV2 (parsePromptInputV2Editor / onPaste)

Description

OpenCode Desktop on Windows can become completely unresponsive when pasting a large technical prompt, audit report, log, or structured specification into the composer.

This appears to be a renderer/UI hang, not simply model/provider latency. The backend/agent side can remain alive while the Desktop UI is frozen.

This appears related to #43935, but my case is on Windows x64 and manifests primarily as repeated renderer hangs rather than a full renderer crash/OOM loop.

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 prompt, report, log, or technical specification directly into the OpenCode Desktop composer, the UI can become extremely slow or fully unresponsive.

The debug bundle contains 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 captured stacks repeatedly point to the prompt-editor paste/input path:

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

Other captured samples during the same type of freeze include:

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

Multiple independent Windows renderer-hang samples therefore converge on the same parsePromptInputV2Editor / onPaste area.

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 primary root cause, but there appears to be significant layout/reactive churn around the same renderer sessions.

Hang vs crash

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

The observed behavior is primarily a renderer hang / UI freeze, rather than a full application crash.

The application may eventually recover without terminating.

Additional system-pressure finding

The same debug package captured a separate Windows subprocess failure:

0xC000012D — STATUS_COMMITMENT_LIMIT

followed shortly afterward by:

0xC0000142 — STATUS_DLL_INIT_FAILED

The machine therefore also experienced Windows virtual-memory pressure during a long-running development workload.

I currently consider this secondary to the paste-specific renderer issue because the renderer samples repeatedly identify the paste/editor path.

Steps to reproduce

Open an existing OpenCode Desktop development session on Windows.

Copy a large technical prompt, log, audit report, or structured specification.

Paste it directly into the composer.

The UI becomes extremely slow or Windows reports the application as not responding.

It may eventually recover without a full process crash.

Expected behavior

Large pasted input should not synchronously block the Electron renderer.

Possible mitigations may include:

Moving expensive paste parsing/normalization away from the renderer main thread where possible.

Chunking or yielding during large-input processing.

Avoiding repeated whole-editor traversal.

Avoiding repeated complete serialization of large prompt state.

Reducing unnecessary reactive/layout updates.

Adding a safe large-paste threshold.

Showing a warning when unusually large input is detected.

Representing very large pasted blocks more efficiently instead of continuously parsing/rendering the complete payload.

Debug data available

I have the complete debug bundle:

opencode-debug-20260914T213910.zip

It contains:

Window logs

Renderer logs

Server logs

Network logs

Crash-reporting information

Timestamps and process behavior

I have intentionally not uploaded the raw archive publicly yet because debug bundles may contain local paths or environment information.

I can provide a sanitized version if needed.

I can also provide reproduction prompt sizes, another debug capture, Windows memory diagnostics, or additional timestamps.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response