anomalyco / anomalyco/opencode
[Desktop][Linux] NodeService utility process SIGABRTs during native teardown on every close
@Brendonovich is already working on this.
Since Sep 8, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Description
[Desktop] NodeService utility process terminates with SIGABRT during native teardown on every close (SteamOS)
Environment
- Steam Deck (holo) / SteamOS 3.8.16
- OpenCode Desktop 1.18.25 (Flatpak
ai.opencode.opencode, Electron 42.3.3) - Kernel pipes all coredumps:
core_pattern = |/usr/bin/python -m steamos_log_submitter.hooks.coredump %P %e %u %g %s %t %c %h %f %E,core_pipe_limit = 16
Problem
Closing OpenCode (last window/session) reliably terminates its Electron utility process (--type=utility --utility-sub-type=node.mojom.NodeService, which hosts the OpenCode sidecar server) with SIGABRT during native teardown — even though the sidecar reports a clean exit. OpenCode's own logs show sidecar exited { code: 0 } at close, while the kernel records a coredump for that same process in the same second. Users observe high CPU/fan ramp for minutes after closing the app, and a lingering ai.opencode.desktop --type=utility ... entry in ps.
Strongest evidence
A live capture tied the crash directly to the session under investigation:
- Host PID 66690 was the OpenCode
node.mojom.NodeServiceutility process for that session. Its/procstatus showedNSpid: 66690 92, linking the host process to the in-sandbox process, withCoreDumping: 1andThreads: 22. coredumpctland the systemd journal recorded PID 66690 terminating with SIGABRT at close time (14:47:12), matching the sidecar's clean-exit log linesidecar exited { code: 0 }at 14:47:12.650 to the second.CoreDumping: 1shows the apparent post-close "survivor" is not a live orphan: it is the crashed process's corpse, held unreaped while the coredump pipeline processes it (the kernel does not reap a crashed task until thecore_patternpipe consumer finishes; nothing is left listening on the sidecar's loopback port afterward).- Correlation across all retained records: 15/15 surviving shutdown records match a
sidecar exited { code: 0 }log entry to the second with a subsequent NodeService SIGABRT coredump (36 OpenCode coredumps total in ~8 days on this machine; OpenCode's owncrash.lognever records any of them — the abort bypasses the app's crashpad reporting). - Separately, there are historical SIGILL shutdown events involving the main Electron process (thread 23), also at session close. These are the closes where the main process died first and no
sidecar exitedline was logged. - The exact native teardown component responsible for the abort has not been identified. The crash occurs after the sidecar's JavaScript has already run
process.exit(0), i.e., inside Chromium/Node native teardown, so it is not visible to OpenCode's logging or crash reporting.
Relevant code path (from app.asar, out/main/index.js): window-all-closed → app.quit() (line ~4407); before-quit/will-quit fire void stopSidecars() (fire-and-forget, not awaited, ~4242–4248), which posts {type:"stop"} to the utility process; out/main/sidecar.js handles stop by stopping the listener and calling process.exit(0).
Secondary: SteamOS coredump pipeline amplifies the impact
This is a separate layer on top of the crash itself, not its cause:
- SteamOS's
core_patternpipes the SIGABRT coredump intosteamos_log_submitter.hooks.coredump, which references the OpenCode PID in its arguments (%P). - Observed during one close: the coredump submitter at ~88.6% CPU, still ~64.7% after several minutes;
systemd-coredumpat ~82% CPU in parallel;drkonqi-coredump-processoralso participated. - The crashed process had roughly 430 MB RSS at the time. Note: Electron's ~1.5 TB
VmPeak/virtual address space is not 1.5 TB of RAM or data — but large sparse address spaces make dump capture/processing slow. - The coredump was reported as truncated (
COREDUMP_TRUNCATED=1). - Net effect: sustained CPU / fan / thermal load for minutes after closing OpenCode, plus a dead-but-visible process entry — presenting as a "process leak" or "app didn't close" symptom.
Reproduction
On this machine, every close does this:
- Launch OpenCode.
- Use it normally (prompt duration/workload does not appear to matter).
- Close the final OpenCode window/session.
- Observe the NodeService utility process terminate abnormally and a coredump appear (
coredumpctlshows a freshai.opencode.desktopSIGABRT entry). - Observe prolonged coredump processing / elevated CPU afterward.
No more precise reproduction condition has been established — the crash was not narrowed to a specific workload, and short sessions crash on close as well.
Expected behavior
Closing OpenCode should terminate its processes cleanly, without SIGABRT/SIGILL coredumps, and without triggering a large coredump-processing workload afterward.
Maintainer takeaway
Two things are worth investigating:
- Why does the Electron NodeService abort during native teardown after the sidecar has already exited cleanly (
exit 0→ SIGABRT microseconds later)? This is the primary issue: a deterministic shutdown-path crash in the Electron utility/browser teardown on this environment, invisible to OpenCode's own crash reporting. A coredump stack from an affected close (e.g., viacoredumpctl info <pid>) should identify the aborting component. - Whether the SteamOS coredump interaction (minutes of ~1-core CPU per close) is expected or can be reduced independently — secondary, and a SteamOS-side question, but it is what turns an invisible shutdown crash into a noticeable thermal/CPU event for users.
Plugins
None. I have a small local modification to OpenCode that triggers the sound notification when user interaction/dialogue is required.
OpenCode version
1.18.8
Steps to reproduce
- Launch OpenCode.
- Use it normally (prompt duration/workload does not appear to matter).
- Close the final OpenCode window/session.
- Observe the NodeService utility process terminate abnormally and a coredump appear (
coredumpctlshows a freshai.opencode.desktopSIGABRT entry). - Observe prolonged coredump processing / elevated CPU afterward.
Screenshot and/or share link
No response
Operating System
SteamOS 3.8.16 (Steam Deck)
Terminal
N/A — OpenCode Desktop (Flatpak)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.