Skip to content

fix(process): spawn opencode.exe directly on Windows to prevent visible console window#159

Merged
grinev merged 2 commits into
grinev:mainfrom
danieliyahu1:fix/windows-opencode-hidden-window
Jul 2, 2026
Merged

fix(process): spawn opencode.exe directly on Windows to prevent visible console window#159
grinev merged 2 commits into
grinev:mainfrom
danieliyahu1:fix/windows-opencode-hidden-window

Conversation

@danieliyahu1

Copy link
Copy Markdown
Contributor

Description

When the bot starts the OpenCode server (via /opencode_start\ or \OPENCODE_AUTO_RESTART_ENABLED), a visible console window appears on Windows. The expected behavior is for the server to start silently in the background.

Root cause

\createOpencodeServeSpawnCommand\ spawns \cmd.exe /c opencode serve\ on Windows. The \windowsHide: true\ flag only applies to the \cmd.exe\ process, not to \opencode.exe\ that \cmd.exe\ launches through the .cmd\ npm shim. \opencode.exe\ gets a fresh console.

Fix

Spawn \opencode.exe\ directly instead of going through \cmd.exe /c. The .exe\ path is resolved from the npm prefix. With \windowsHide: true\ applying directly to \opencode.exe, no console window appears.

Changes

  • \src/opencode/process.ts: added
    esolveWindowsOpencodeExe()\ helper, rewrote \createOpencodeServeSpawnCommand\ to spawn .exe\ directly on Windows
  • \ ests/opencode/process.test.ts: updated Windows test assertion to verify \windowsHide: true\ and that \cmd.exe\ is no longer used

Testing


  • pm run build\ — pass

  • pm run lint\ — zero warnings

  • pm test\ — 999/999 passing (Windows)

@grinev

grinev commented Jun 18, 2026

Copy link
Copy Markdown
Owner

@danieliyahu1 Doesn't work on my windows PC. The fix idea is right, but resolveWindowsOpencodeExe() resolves the wrong directory — path.dirname(process.execPath) is the Node.js folder, not the npm global prefix (on Windows that's usually %APPDATA%\npm). So the candidate path doesn't exist and it falls back to "opencode.exe", which spawn() can't find (only the .cmd shim is on PATH, not the .exe).
Result: spawn opencode.exe ENOENT, and /opencode_start fails on a default global install. Seen it in the logs.
You'll need to resolve the npm prefix correctly (e.g. from the opencode.cmd location on PATH), and keep a safe fallback for when the .exe isn't found. Also, the test only checks command !== "cmd.exe", so it passes even when resolution is broken — worth making it assert a real path.

- Locate opencode.cmd on PATH and derive real opencode.exe path

- Fall back to cmd.exe /c opencode when exe cannot be resolved

- Add tests to catch ENOENT-style resolution bugs
@danieliyahu1

Copy link
Copy Markdown
Contributor Author

Pushed an updated fix to the PR branch.\n\nChanges:\n- Resolve the real Windows opencode.exe by locating opencode.cmd on PATH and deriving \node_modules\opencode-ai\bin\opencode.exe\n- Safe fallback to cmd.exe /c opencode serve when the exe cannot be resolved\n- Strengthened tests to fail if Windows returns a bare 'opencode.exe' (prevents ENOENT regressions)\n\nRepro on a default Windows install: opencode.exe is typically not on PATH (only opencode.cmd), so the old fallback caused spawn ENOENT. The new tests cover both the fallback and resolved-exe cases.

@grinev

grinev commented Jul 2, 2026

Copy link
Copy Markdown
Owner

@danieliyahu1 thanks for contribution!

@grinev grinev merged commit 9f9b87e into grinev:main Jul 2, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants