MCP Subsystem entirely unresponsive on Windows Desktop App (/config loads, but /mcp times out)

[Yanjy-Nov10]

Description

It appears that the entire MCP subsystem on the current OpenCode Windows Desktop instance is completely unavailable. This is not an issue with a specific MCP directory or configuration, but rather a systemic failure of the MCP runtime/integration on the Windows environment.

Plugins

No response

OpenCode version

1.2.20

Steps to reproduce

Observations & Evidence:

Universal Failure: Both previously working MCP entries and newly configured MCP entries fail to start within OpenCode.

MCPs are healthy standalone: When I manually run these MCPs directly in the system terminal (e.g., node dist/index.js), they work perfectly. They remain active and do not crash/exit immediately.

Config is read successfully: The OpenCode /config endpoint returns data normally, proving that OpenCode successfully reads and parses the MCP configurations.

Connection/State check fails: The OpenCode /mcp endpoint frequently times out or disconnects internally.

Troubleshooting Performed:
I have thoroughly isolated the issue from the "configuration layer" and the "command layer":

Tested both global and project-level configurations.

Replaced bare commands with absolute paths.

Switched from using .cmd scripts to explicitly calling node.exe + dist/index.js.

Verified that the MCP services themselves are fully functional outside of OpenCode.

Conclusion:
The root cause is no longer a configuration error or a broken MCP script. The evidence clearly points to a bug in OpenCode's own MCP runtime / desktop integration under Windows.

The fact that /config works while /mcp times out suggests that OpenCode's internal process scheduling, state checking, or IPC (stdio) connection subsystem has stalled or broken down.

Screenshot and/or share link

Operating System

windows 11

Terminal

No response

[github-actions]

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

• Stdio handshake timeout with npx local MCPs (env expansion suspect) #12229: Stdio handshake timeout with npx local MCPs — similar symptom of MCP servers timing out while running commands manually works fine
• Windows MCP local server fails with Bun but works with NPX (Error -32000) #6994: Windows MCP local server fails with Bun but works with NPX — Windows-specific MCP connection failure where the MCP runtime fails to establish stdio communication

If your issue is distinct from these, please add any additional details that differentiate it (e.g., specific error messages from debug logs, whether it's all MCP transport types or just stdio/local).

[Yanjy-Nov10]

I’m seeing a broader local MCP failure on Windows desktop OpenCode that looks related to existing stdio/handshake issues, but not identical to either:

#12229 — local stdio MCP handshake timeout with npx
#6994 — Windows local MCP with bun fails, but npx works
In my case, the problem is wider:

local stdio MCPs fail not only with bun, but also with:
npx
bare command names from PATH
.cmd wrappers
direct node.exe <dist/index.js>
the same MCP servers run fine when started manually outside OpenCode
OpenCode can read config successfully, but the MCP runtime layer is unstable:
/config works
/mcp either returns MCP error -32000: Connection closed
or hangs / times out entirely
This affects both existing built-in/local MCP entries and newly configured local MCPs.

Environment
OS: Windows 11
Client: OpenCode Desktop
OpenCode runtime observed: opencode-cli.exe serve --hostname 127.0.0.1 --port <random_port>
Transport affected: local stdio MCP
Transport not clearly affected the same way: some remote MCPs can connect, but many remote/default MCPs also cause startup slowness or hanging
Affected local MCPs
Examples I tested:

filesystem
fetch
sequential-thinking
git-local
context7
puppeteer
github
What I verified

1. OpenCode sees the MCP config
   OpenCode local API /config returns the configured MCP entries correctly.

I verified both:

global config
project-level config
So this is not just “config file not loaded”.

2. Manual execution works
   Running the MCP servers directly on Windows works fine.

Examples:

node.exe .../@modelcontextprotocol/server-filesystem/dist/index.js
node.exe .../@modelcontextprotocol/server-sequential-thinking/dist/index.js
node.exe .../@cyanheads/git-mcp-server/dist/index.js
node.exe .../@modelcontextprotocol/server-github/dist/index.js
Observed behavior:

process stays alive
server reports it is running on stdio
no immediate crash / no immediate exit
So this is not a broken package install.

3. OpenCode MCP runtime fails
   Inside OpenCode, the same local MCPs fail.

Observed patterns:

sometimes /mcp returns entries like:
status: failed
error: MCP error -32000: Connection closed
after restart / on some instances:
/mcp itself hangs and times out
/config still works while /mcp is stuck
4) Explicit connect does not fix it
I also tried explicit connect calls through the local OpenCode API:

POST /mcp/{name}/connect
These returned 200 true, but the MCPs still ended up as failed / closed afterward.

5. This is not Bun-specific
   Unlike Windows MCP local server fails with Bun but works with NPX (Error -32000) #6994, this is not resolved by switching away from Bun.

I tested multiple local command styles and the failure persists:

bun family not required to reproduce
npx still fails
direct node.exe + dist/index.js still fails when launched by OpenCode
Reproduction pattern
Configure one or more local stdio MCP servers in OpenCode on Windows
Start or restart OpenCode Desktop
OpenCode loads the config (/config confirms this)
Local MCPs do not become usable
Depending on the instance:
they show Connection closed
or /mcp hangs / times out
Expected behavior
Local stdio MCPs should connect and remain available in OpenCode, especially when:

the same exact command works manually
the process stays alive outside OpenCode
config is clearly loaded by OpenCode
Actual behavior
OpenCode loads the config
local stdio MCPs still fail internally
OpenCode may become very slow
MCP runtime status endpoint may hang
local MCPs are effectively unavailable
Why this seems different from existing issues
Similar to #12229
local stdio MCPs fail inside OpenCode
manual execution works
suggests a handshake / runtime integration issue
Similar to #6994
Windows-specific symptoms
can produce MCP error -32000: Connection closed
Different from both
failure is not limited to Bun
switching command style does not help
even direct node.exe <dist/index.js> launched by OpenCode still fails
issue seems broader than a single wrapper/runtime problem
OpenCode local MCP subsystem may become unstable enough that /mcp itself hangs
Additional notes
One more thing I observed:

OpenCode Desktop’s local backend port changes between restarts
after restart, behavior can vary between:
immediate Connection closed
or /mcp timing out entirely
This makes it look like a desktop runtime / local MCP integration instability on Windows, not just a single bad MCP server.

[Yanjy-Nov10]

你这种问题我经历过，所以我现在不怎么敢用mcp了，你可以先尝试把哪些需要的mcp先记住名字或者隔离备份，记得备份好你重要的东西，skill，mcp，memory，尝试重装试试看

好的我尝试一下，感谢！

[simmessa]

I can confirm that I've been fighting with enabling searxng MCP on Opencode desktop on Windows 11 and I couldn't make it work, this is very limiting. Hope this gets sorted out soon.