Repository navigation
Desktop: sidecar crashes on 2nd LLM call when oh-my-opencode plugin loaded (Windows) #27723
Description
Description
Environment
- OpenCode Desktop: v1.15.0 (Windows x64)
- OpenCode CLI: v1.15.0 (same machine, works perfectly)
- OS: Windows 10/11 (Build 26200)
- Plugin:
oh-my-opencodev4.1.2 (npm:oh-my-opencode/oh-my-openagent)
Bug Description
When the oh-my-opencode plugin is loaded, the Desktop app's sidecar process (running as Electron node.mojom.NodeService utility process) crashes deterministically on the 2nd LLM streaming call. The 1st message always succeeds. The CLI version with the exact same config, binary version, and API works perfectly.
Reproduction Steps
- Install OpenCode Desktop v1.15.0 on Windows
- Configure
opencode.jsoncwith"plugin": ["oh-my-opencode"] - Open Desktop app, start a new session
- Send 1st message → succeeds, LLM responds normally
- Send 2nd message → sidecar process dies immediately, DevTools shows
net::ERR_CONNECTION_REFUSEDfor all subsequent requests
What Happens
- The sidecar runs inside Electron's utility process (
--type=utility --utility-sub-type=node.mojom.NodeService) - On the 2nd LLM call, the utility process is killed (no crash dump, no error log, no Windows Event Log entry)
- The Electron shell remains alive, but the frontend loses connection to the sidecar
- DevTools console shows:
[global-sdk] event stream error → {url: 'http://127.0.0.1:<port>', fetch: 'webview', error: TypeError: network error} GET http://127.0.0.1:<port>/global/health net::ERR_CONNECTION_REFUSED
Diagnosis Details
Verified via process monitoring:
16:44:21 alive WS=238MB ← 2nd message sent
16:44:23 alive WS=322MB ← memory spikes
16:44:35 SIDECAR DIED! ← process vanishes
Main process: ALIVE ← Electron shell still running
What was ruled out:
| Factor | Tested | Result |
|---|---|---|
| API connectivity | curl tests (streaming + non-streaming) | ✅ All 200 OK |
| MCP servers | Disabled all MCP (enabled: false) |
❌ Still crashes |
| Plugin cache corruption | Deleted all plugin caches, fresh install | ❌ Still crashes |
| Snapshot lock files | Cleaned .local/share/opencode/snapshot |
❌ Still crashes |
| Electron cache | Cleared Session Storage, GPUCache, Code Cache | ❌ Still crashes |
| Version regression | Tested v1.14.50 | ❌ Still crashes |
| Plugin disabled | "plugin": [] |
✅ Stable (2min+ monitoring, multiple messages) |
| Plugin enabled | "plugin": ["oh-my-opencode"] |
❌ Crashes on 2nd message |
Key difference: Desktop vs CLI
- CLI (standalone Node.js process): Works perfectly with the plugin, unlimited messages
- Desktop (Electron utility process
node.mojom.NodeService): Crashes on 2nd LLM call with plugin loaded
Expected Behavior
The Desktop sidecar should handle multiple LLM calls with plugins loaded without crashing, same as the CLI version.
Workaround
Disable the plugin in Desktop: "plugin": []. Use CLI for full plugin functionality.
Hypothesis
The oh-my-opencode plugin likely performs operations (child process spawning, native module loading, or unhandled async errors) that are incompatible with Electron's utility process sandbox. The utility process may have stricter resource limits or different process lifecycle management compared to a standalone Node.js process. The silent death (no crash dump) suggests the parent Electron process is killing the utility process rather than the utility process crashing on its own.
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
Activity
github-actions commentedon May 15, 2026
This issue might be a duplicate of an existing issue. Please check:
oh-my-openagent/oh-my-opencode) causing Desktop sidecar crashes, same root cause (plugin behavior incompatible with Electron utility process), same workaround (remove plugin from config). The crash mechanism differs slightly (yours is deterministic on 2nd LLM call on Windows; Desktop sidecar exits silently with code 1 — third-party plugin's global uncaughtException handler calls process.exit(1) on any unhandled rejection in the sidecar #27557 is a silent exit over time on macOS), but both trace to the same plugin's global error handler design.If your issue is distinct from #27557, please clarify how it differs so it can be tracked separately.
nieaowei commentedon May 15, 2026
The same error on MacOS. The only information I got:
main.log:
[2026-05-15 19:20:57.716] [warn] sidecar exited { code: 1 }
nieaowei commentedon May 15, 2026
Find a temporary solution: code-yeongyu/oh-my-openagent#3997 (comment)
fix: rehydrate member registry on every plugin init
herbie4106 commentedon May 22, 2026
Same issue confirmed on Windows 11.
Environment
Crash details
Exit code: 3221226505 (0xC0000409 = STATUS_STACK_BUFFER_OVERRUN)
Log evidence (utility.log):
[2026-05-26 08:40:06] (utility) sidecar exited { code: 3221226505 }
Pattern
Note
The
disabled_hooks: ["session-notification"]workaround from #3997 does NOT prevent this crash. This appears to be a separate code path from the exit code 1 / session-notification issue.github-actions commentedon Jul 26, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.