OpenCode v1.1.53 randomly crashes during usage on Windows.

[mynameistito]

Description

Issue: opencode v1.1.53 randomly crashes during usage

Crash Evidence:

• Crash logs end abruptly after loading config files (4-5 lines, ~400 bytes)
• Successful logs continue to server startup (800KB-3.7MB)
• No error messages - silent termination
• Pattern: crash → immediate successful restart (~1 sec later)

Technical Details:

• Timing: Crashes occur at 00:13:27, 00:16:16, 00:17:17, 00:20:49 - all ~1-2 seconds before successful starts
• Missing in crashes: Plugin loading, server initialization, LSP setup
• MCP Errors (non-fatal): MCP error -32601: Method not found for context7/grep_app prompts
• Warnings: 20+ duplicate skill warnings across .claude/skills/, .agents/skills/, .config/opencode/skill/
• LSP Servers: 35+ enabled (deno, typescript, vue, eslint, biome, etc.)

Environment:

• Windows x64
• Warp Terminal
• Bun - 1.3.9
• Node - 24.13.0

Plugins

• "opencode-antigravity-auth@beta",
• "opencode-anthropic-auth@latest",
• "opencode-sync-plugin@latest",
• "@mohak34/opencode-notifier@latest"

AI Hypothesis:

Race condition during config file reading or plugin initialization phase, possibly related to file locking or async timing on Windows.

AI Assisted Issue

[github-actions]

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

• OpenCode crashes during use on Windows (garbled console output) #10414: OpenCode crashes during use on Windows (garbled console output) - Direct match: Windows-specific crashes during runtime with similar low-level process/file handling issues
• Win11下，无法打开OpenCode #6919: Can't open OpenCode on Win11 - Windows 11 startup/launch failure with similar symptom pattern (unable to launch)
• Opencode become stuck all of a sudden. Does not launch anymore. #5485: Opencode become stuck all of a sudden. Does not launch anymore - Related process hanging and launch failure

Feel free to ignore if none of these address your specific case.

[mynameistito]

I think I found the issue, I believe it was due to there being duplicate skills in different routes.

[DrDexter6000]

Root Cause Identified: Node.js v24 Silent Process Termination on Windows

This issue appears to be caused by a Node.js runtime bug, not an OpenCode logic error.

Upstream bug: nodejs/node#62125 — Node.js v24.13.x on Windows silently terminates child processes (including those spawned with \child_process.spawn()) via \TerminateProcess()\ with no JS exit handlers firing, no diagnostic report, and no Event Log entry. The process simply vanishes.

Why this matches the symptoms in this issue

• Silent crashes with no error output — exactly what \TerminateProcess()\ causes (bypasses all JS cleanup)
• Node 24.13.0 in the reporter's environment — the affected version range
• Crash logs end abruptly — the process is killed externally before it can write anything
• Immediate successful restart — the crash is caused by the runtime, not by application state corruption

Independent verification

We independently encountered this exact bug while debugging a Chrome Native Messaging host chain on Windows. Our findings:

• A bare \setInterval(() => {}, 1000)\ in a detached spawn dies in ~4-6 seconds on v24.13.1 — zero I/O, zero business logic needed to reproduce
• All exit handlers fail to fire: \process.on('exit'), \process.on('SIGTERM'), \process.on('uncaughtException')\ — none trigger
• Python equivalent survives indefinitely under identical conditions — this is Node.js-specific
• Downgrading to Node.js v22.22.2 LTS resolves the issue completely (137+ seconds uptime verified)

Workaround

`

Use Node.js v22 LTS instead of v24

nvm install 22
nvm use 22
`

Or, if you need v24 for other reasons, spawn long-lived child processes using a v22 binary specifically:

\\javascript
const nodeV22Path = 'path/to/node-v22.exe';
spawn(nodeV22Path, ['your-script.js'], { detached: true, stdio: 'ignore', windowsHide: true });
\\

Note for maintainers

OpenCode's own \�ash.ts\ and \cross-spawn-spawner.ts\ already correctly set \detached: false\ on Windows, which is good defensive coding. However, when users run via
px\ on Node v24, the runtime-level bug can still affect the host process itself and any indirectly spawned children (e.g., MCP stdio transports, plugin processes).

Suggest adding a Node version check at startup that warns Windows users on v24.x about this upstream bug.

[DrDexter6000]

Important Update: Windows Security Behavioral Detection Confirmed

After further investigation, we now have direct evidence that Windows Security (Defender) behavioral detection is killing detached child processes on Windows. This may be a contributing factor alongside any Node.js v24 runtime behavior.

Evidence

On 2026-04-06 at 08:23 local time, while running minimal detached spawn reproduction tests with Node.js v24.13.1 on Windows 11, Windows Security flagged and terminated the test script:

• Detection: Trojan:Win32/SuspExec.SE (Suspicious Execution)
• Status: Removed (process killed)
• Action: The process was terminated immediately with no notification to the Node.js runtime

The Windows Security Protection History shows the exact command line that was flagged. The test script was a minimal reproduction: spawn a detached node -e 'setInterval(()=>{},1000)' child, then poll it with process.kill(pid, 0).

Why This Pattern Triggers Detection

Windows Security behavioral analysis flags this pattern because it resembles C2 beacon/persistence behavior:

1. PowerShell writes a script to disk
2. Script spawns a detached, never-exiting child process
3. Parent polls child liveness at regular intervals
4. Child has no visible I/O or user-facing activity

This is indistinguishable from malware persistence techniques at the behavioral level.

Key Observation: Other Tools Work Fine

On the same machine, other browser automation tools work without issues:

• Claude Code (desktop): browser automation works perfectly
• Manus AI (web): browser automation works perfectly

This suggests the issue is not purely a Node.js v24 runtime bug. If it were, all Node.js-based tools would be equally affected.

Revised Hypothesis

The root cause is likely a combination of factors:

1. Windows Security behavioral detection (confirmed): kills processes that match the SuspExec pattern, regardless of digital signature validity. The detection is behavior-based, not signature-based.
2. Node.js v24 compatibility: Windows Security may not have whitelisted/recognized the behavioral profile of Node.js v24 yet (newer runtime = fewer established behavioral patterns = higher false positive rate).
3. Spawn pattern similarity to malware: detached: true + stdio: 'ignore' + child.unref() + polling is exactly how many persistence implants work.

Why Node v22 LTS Works

Node v22 LTS has been around longer. Windows Security has likely built behavioral whitelisting for common Node.js v22 spawn patterns. Node v24 is newer and its behavioral profile may not be fully recognized yet.

Updated Workaround

In addition to using Node v22 LTS, also consider:

1. Add your project directory to Windows Security exclusions (Settings > Privacy & Security > Windows Security > Virus & Threat Protection > Exclusions)
2. Use Node v22 LTS for spawning long-lived detached processes: nvm install 22 && nvm use 22
3. If developing/testing detached spawn patterns on Windows, be aware that Windows Security real-time protection may silently kill your processes

This finding also explains the "invisible hand" effect we observed: processes dying after ~4-6 seconds with zero diagnostic output, zero JS exit handlers firing, and zero Event Log entries. Windows Security TerminateProcess() produces exactly this symptom profile.

[DrDexter6000]

⚠️ Correction: Root Cause Was Windows Defender, Not Node v24 Bug

TL;DR: Our original diagnosis was wrong. The actual root cause was Windows Defender behavior detection (Trojan:Win32/SuspExec.SE), not Node.js v24 silently terminating detached processes.

What Changed

After adding Windows Defender exclusions for OpenCode.exe, opencode-cli.exe, node.exe, and their install directories:

• Node v24.13.1 detached spawn: ✅ Stable 8+ seconds (previously died at 4-6s)
• Chrome headless launch: ✅ Normal (previously killed by Defender)
• CDP browser automation (full chain): ✅ Tab create → navigate → JS eval → DOM modify → close — all pass

The same Node v24.13.1 binary, same code, same machine — the only change was Defender exclusions.

Corrected Diagnosis

Before (Wrong)	After (Correct)
Node v24 silently terminates detached children via TerminateProcess()	Windows Defender behavior detection flags AI coding agent processes as Trojan:Win32/SuspExec.SE and kills them
Workaround: downgrade to Node v22	Workaround: add Defender exclusions for AI coding tools
nodejs/node#62125 is the root cause	nodejs/node#62125 may still be a real issue under other conditions, but our specific reproduction case was Defender

Why the Misdiagnosis

1. TerminateProcess() was called — but by Windows Defender, not Node.js internals
2. No exit handlers fired — because Defender's TerminateProcess() is a forced kill, identical behavior to what we attributed to Node
3. Python survived — not because of language differences, but because Defender's heuristic didn't flag Python processes the same way
4. Digital signature was valid — Defender uses behavioral heuristics, not just signature checks

Evidence Log

• Windows Security popup: Trojan:Win32/SuspExec.SE detected during debugging session
• Claude Code and Manus AI browser automation worked fine on same machine (different process signatures)
• After Defender exclusions: all tests pass, including bare setInterval detached spawn on v24.13.1

Apologies for the initial misattribution. The nodejs/node#62125 issue may still be valid for other reporters — we can only correct our own reproduction case.

---

Root cause analysis documented at: [Gist link TBD]