Desktop: server sidecar crashes repeatedly (0xC0000409) under memory pressure; image-count errors also brick sessions

��### Description

Two related but distinct problems observed on desktop 1.18.30 (Windows 11, x64, 48GB RAM). Debug bundles: opencode-debug-20260912T132111, opencode-debug-20260912T184636, opencode-debug-20260912T205525.

1. Session fails permanently with "Too many images in request"

When a session accumulates more images than the provider accepts per request (Console Go limit: 30), every request fails with:

AI_APICallError: Error from provider (Console Go): Upstream request failed: [invalid_request_error] Too many images in request: 31 > 30

This message is not classified as context overflow, so auto-compaction never triggers and every retry rebuilds the request with the same images. Manually compacting recovers the session (which confirms compaction with media stripping is the right remedy), but the app should do this automatically.

Fix proposed in #48716. Related: #47493 (also caps images per request), #40167 (same classification for Azure).

2. Server sidecar crashes repeatedly (the bigger problem)

Roughly every 30���90 minutes of active use, the opencode server process spawned by the desktop app dies with exit code 3221226505 (0xC0000409, STATUS_STACK_BUFFER_OVERRUN ��� the fast-fail abort V8/Node uses on unrecoverable errors such as OOM commit failure). The renderer then shows fatal renderer error: TypeError: Failed to fetch and the app asks to restart/report.

Evidence from the exported bundles (desktop/<run>/utility.log in every one of the three zips):

[warn]  (utility)    sidecar exited { code: 3221226505 }
[error] (utility)    child process gone { reason: 'crashed', serviceName: 'node.mojom.NodeService', name: 'opencode server' }

This is not a one-off: utility.log across 37 desktop runs from 2026-09-05 to 2026-09-12 shows 30 crashes with code 3221226505 (and only 3 clean exits with code 0). Windows Error Reporting also logged a RADAR_PRE_LEAK_64 memory-leak detection for OpenCode.exe 1.18.29 on 2026-09-05.

Correlation with server-1/opencode.log: in every crash window, the last server activity is an agent loop mid-run, typically right after evaluating a bash permission for a Gradle build (.\gradlew :app:androidApp:assembleDebug ...) or a file-format step. Gradle/Kotlin daemon + Electron + the Node sidecar together can push the commit charge over the limit (pagefile is only 3GB on this machine), and the Node process aborts with 0xC0000409. The server log itself ends abruptly with no FATAL/OOM entry, consistent with a hard abort rather than a handled error.

Steps to reproduce

1. Use the desktop app on a long-running session (agent loop running Gradle builds in parallel with editing).
2. After some minutes, the server dies: UI shows "Failed to fetch"/restart dialog; app must be restarted.
3. Happens repeatedly, several times per day.

Expected behavior

• The server should survive (or at least degrade gracefully with a visible error) under memory pressure; the desktop should restart the sidecar automatically instead of requiring a full app restart.
• The image-count failure should trigger auto-compaction instead of bricking the session.

Actual behavior

• Sidecar aborts with 0xC0000409 ~30 times/week; desktop requires manual restart each time.
• Image-count errors are surfaced as plain API errors; session bricks until manual compaction.

---

Update 2026-09-13: crash survives larger pagefile  heap pressure profiled

After setting a fixed 16 32GB pagefile (commit now 64GB total), the sidecar still crashed with 0xC0000409 while a Gradle build ran inside an agent loop. Further profiling of the local install:

• opencode.db is 4GB. The event table alone holds 3.2GB across 244k rows (message.updated.1 = 3.2GB, with 339 events over 1MB each).
• The three sessions involved in crashes have 2.0k 2.6k messages and 8.2k 10.9k parts each (46 50MB of part JSON per session).
• The sidecar's private memory oscillates 0.7 1.0GB under an active loop; per-turn work (filterCompactedEffect �! structuredClone �! toModelMessagesEffect �! token estimation over the whole history) multiplies that transiently several-fold.
• Every observed crash (including the post-pagefile one at 22:47 local) happens mid-loop, right after evaluating a bash permission for gradlew assembleDebug.

So the abort is consistent with the V8 heap limit being exceeded while rebuilding/serializing a very large session history under concurrent native-build memory pressure  not system commit exhaustion anymore.

Mitigations for affected users until this is fixed:

1. Delete/trim the very long-running sessions (the ones with thousands of messages)  this immediately reduces sidecar heap on boot and per turn.
2. Keep Gradle/daemon memory bounded (org.gradle.jvmargs=-Xmx2g in gradle.properties) or run builds outside the agent loop.
3. Fixed 16 32GB pagefile helps but is not sufficient on its own.

Fix direction worth discussing with maintainers: incremental history conversion (avoid full-history clone/serialize per turn), capping media retention in old parts, and the sidecar respawn from PR #48716 as a last-resort recovery.