Repository navigation
MCP Subsystem entirely unresponsive on Windows Desktop App (/config loads, but /mcp times out) #16449
Description
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
Activity
github-actions commentedon Mar 7, 2026
This issue might be a duplicate of existing issues. Please check:
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 commentedon Mar 7, 2026
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
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”.
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.
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.
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 commentedon Mar 7, 2026
好的我尝试一下，感谢！
simmessa commentedon Apr 9, 2026
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.
github-actions commentedon Aug 27, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.