fix(opencode2): hide background console windows on windows - #45259

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

I can't reproduce this locally. Are you using any plugins?

here my current setup for bug replication if you dont have it natively on your setup:

• On windows 11
• Open terminal, go to settings
• Set Powershell 7 as the default profile (not microsoft powershell 5.x)
• Set Microsoft Console Host as the default new terminal application
• pwsh.exe (powershell 7+)
• opencode2
• Ask any claude or gpt model to grep "hello world" in the sub folders
• Minimize to desktop to be sure it doesnt spawn under your window

I was not able to replicate it on Linux.

Drafting it, still able to replicate the bug in some cases

prompt was just "grep for hello world in this folder"
https://github.com/user-attachments/assets/b89642d0-58f9-4bfd-a88a-d01f7fde6781

Still reproducible on v2.0.11 (Windows 11, Desktop build). Worth flagging that there is a second, independent spawn path that this patch does not cover, so hiding spawnServiceContender alone won't make the symptom go away.

The path I can reproduce deterministically is local stdio MCP launchers. With npx-based MCP entries in opencode.json:

opencode-cli.exe serve --service
└─ cmd.exe /d /s /c "npx -y @playwright/mcp@latest --config <path>"
   └─ node.exe .../npm/bin/npx-cli.js
      └─ cmd.exe /d /s /c playwright-mcp --config <path>

Two cmd.exe per MCP server, and — separate bug — they are never reaped. On a normal session I ended up with 81 live cmd.exe: 45 direct children of opencode-cli.exe (12 × magicui, 12 × playwright, 12 × codegraph, 9 × shadcn) and 34 children of npx-cli.js. Because they are never reaped, the effect isn't the 40–150 ms flash but dozens of persistent windows, all titled C:\WINDOWS\system32\cmd.exe, stacked on the desktop.

That makes this much easier to reproduce/observe than the transient case, and easy to distinguish from the background-service windows:

1. Windows 11, pwsh 7, default terminal (Windows Terminal).
2. Configure 2–4 local npx-based stdio MCP servers.
3. Start OpenCode Desktop 2.0.11, use it normally for a while.
4. Get-CimInstance Win32_Process -Filter "Name='cmd.exe'" | Measure-Object → grows without bound; each entry's parent is the serve --service process or an npx-cli.js node.

For what it's worth regarding "plugins": my setup has plugins enabled, but none of them spawn anything — the parents are unambiguously the serve process and npx-cli.js.

Suggestion: mention in the description that the MCP spawn path (and descendant reaping — see #46253 and #47727) needs the same windowsHide + teardown treatment, otherwise the issue stays open after this lands.

I have exactly the same thing: windows flashing very quickly several times per hour, sometimes even within 1 minute. According to logs, this happens in groups of 5 windows and it is indeed related to the MCP's you're connected with: as OpenCode says: OpenCode's background service spawns every local MCP server via cmd.exe /d /s /c ... (confirmed in the live process tree). Each spawn briefly allocates a visible console window. Your global config made codegraph, lystbot, lemma local servers, plus their npx/shim chains — so one location refresh ≈ 5+ cmd.exe flashes.

It can be solved by removing the MCP's, but well, that's not the idea. It started for me when I updated to the v2 desktop version. Never had it before.

Repro confirmed on opencode v2.0.18 (Windows 11, TUI + Desktop 2.0.18, managed background service).

Spawns in opencode.log, all role=server:

• ~267x C:\Program Files\Git\cmd\git.EXE (snapshot loop: diff-files, ls-files, write-tree) even while idle
• ~26x C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.EXE (one per shell tool call)

Sanitized sample:

timestamp=... message="spawning process" command="C:\Program Files\Git\cmd\git.EXE" args="["diff-files",...]" cwd="" role=server
timestamp=... message="spawning process" command="C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.EXE" args="["-NoLogo","-NoProfile",...]" cwd="" role=server

Process layout when it flashes:

opencode.exe serve --service   (detached, parent dead)
opencode.exe                   (TUI)

A/B on the same machine (spawns still logged in all three, only the visible window differs):

How I tested the contender-side change: shallow-cloned branch v2, applied the one-line change to the service contender spawn, installed Bun 1.4.2 globally, ran bun install, then ran the dev CLI so it re-spawned its own service. Same spawns logged afterwards, visible windows persisted in my setup. The install was removed after the test.

Suggestion: both clean paths already exist in the product, so consider exposing one as a supported no-flash option — either document --standalone for single-client use, or surface a shared-service mode that runs attached to a visible console (what I do manually today: serve --service in a Windows Terminal tab, TUI + Desktop attached to the same service), so users don't have to choose between sharing one service and getting flashes.

Tldr quick fix: add the hidden window flag to all hooks on your harnesses. For PowerShell this is -WindowStyle hidden

I ended up cancelling this and resolving it on my end. Here is the explanation for future readers as I see a lot of activity here still

In opencode v2 every terminal call is made in a new child process terminal window

Even if we merged this, it turns out it does not solve the problem entirely. I did make another pr to fix it completely but it turned out to be quite complex and felt like the wrong approach to the problem.

The windows are now properly hidden for native opencode2 commands. However any additional tools that you have like hooks for pre-commit or shell guards will not be hidden. You have to modify every tool in your harness to spawn a hidden window.

This biggest offender for me was the git rev-parse in a hook to check if we were in a git repo, and then enforce repo conventions if we are. This spawned a bunch of recursive windows.

idk i can't reproduce it, i'll reopen for now and try to figure out exactly what's causing it

@neriousy
Here is what I get at the start of each session and sometimes during subagent calls. The issue is still persistent in 2.0.18.