Activity

1. mynameistito

   added

   bugSomething isn't workingSomething isn't working

   on Feb 9, 2026
2. github-actions

   assigned

   rekram1-node

   on Feb 9, 2026
3. github-actions

   added

   windows

   on Feb 9, 2026
4. github-actions commented on Feb 9, 2026

   

   github-actionsBot

   on Feb 9, 2026 – with GitHub Actions

   Contributor

   More 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.
5. mynameistito commented on Feb 9, 2026

   

   mynameistito

   on Feb 9, 2026

   ContributorAuthor

   More actions

   I think I found the issue, I believe it was due to there being duplicate skills in different routes.
6. DrDexter6000 commented on Apr 6, 2026

   

   DrDexter6000

   on Apr 6, 2026

   More actions

   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.
7. DrDexter6000 commented on Apr 6, 2026

   

   DrDexter6000

   on Apr 6, 2026

   More actions

   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.
8. mynameistito

   closed this as completedon Apr 6, 2026
9. DrDexter6000 commented on Apr 6, 2026

   

   DrDexter6000

   on Apr 6, 2026

   More actions

   ⚠️ 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]