mcp: Windows service registers zero MCP servers from global config

Summary

On Windows, OpenCode 2.0.14 loads the global config from the expected location — providers defined in the same file resolve and opencode debug config reports the MCP servers correctly — but the running service registers zero MCP servers. opencode mcp list prints No MCP servers configured, and GET /api/mcp returns an empty data array for the location. The same config shape on Linux lists and connects the servers normally, so this looks Windows-specific. It is not caused by config content: it reproduces with a 266-byte minimal config containing exactly one MCP server.

Environment

opencode version: 2.0.14 (opencode v2.0.14)
OS: Microsoft Windows NT 10.0.26200.0 (AMD64)
Terminal: not applicable — reproduced from a non-interactive SSH session and from a local opencode mcp list
Shell: pwsh 7.6.6 (ComSpec: C:\WINDOWS\system32\cmd.exe)
Install/channel: latest; installed by extracting the npm platform package @opencode/cli-windows-x64@2.0.14 to C:\Users\<user>\.opencode\bin\opencode.exe (the documented Windows path, since Windows package managers are unsupported)
Active plugins: none in the minimal reproduction. The full config also declares two local plugins; both load cleanly under V2, so they are unrelated.

Reproduction

On Windows, install 2.0.14 and write a minimal global config at C:\Users\<user>\.config\opencode\opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "filesystem": {
      "type": "local",
      "command": [
        "C:\\Program Files\\nodejs\\node.exe",
        "C:\\Users\\<user>\\AppData\\Roaming\\npm\\node_modules\\@modelcontextprotocol\\server-filesystem\\dist\\index.js",
        "C:\\Users\\<user>"
      ]
    }
  }
}

opencode service restart
opencode mcp list → No MCP servers configured
opencode api get /api/mcp → {"location":{"directory":"C:\\Users\\<user>"},"data":[]}
opencode debug config → the same server IS present, under the normalized mcp.servers, with disabled: false

The same outcome occurs with a 20-server real-world config (local node/npx servers, uvx servers, and remote URL servers), and with the V1 flat mcp map as well as with enabled flags removed.

Expected Behavior

opencode mcp list lists each configured server with its connection status, and GET /api/mcp returns them for the current location. On Linux, with an equivalent global config, opencode mcp list prints e.g.:

✓ aria2              connected
✓ claudecodebrowser  connected
✓ playwright         connected

Actual Behavior

On Windows the server catalog is empty:

$ opencode mcp list
No MCP servers configured

$ opencode api get /api/mcp
{"location":{"directory":"C:\\Users\\<user>"},"data":[]}

No mcp connect or mcp connect failed log lines are emitted at all on Windows, i.e. the service never attempts to start any configured server. There is no error to report — the servers are silently absent from the catalog.

Additional Context

Same config, different platform: an equivalent global config on Linux (opencode 2.0.12, Arch/CachyOS) lists and connects four MCP servers, so the config shape is not the problem.
Other parts of the same Windows config DO load: opencode models returns 269 models, including providers defined in the same opencode.json (llama-server, moonshot, claude-code, ollama-cloud). Only mcp is missing.
Not a display issue: GET /api/mcp confirms the service itself has no servers, so this is not just a CLI formatting bug.
Not config content: reproduced with a 266-byte minimal config (one server, V2-native shape). Also tried removing all V1 enabled flags — no difference.
Not a race: repeated invocations after the service is warm return the same empty result, while the identical sequence on Linux returns a populated list.
Config discovery is correct: opencode debug paths reports config = C:\Users\<user>\.config\opencode, and opencode debug config lists that file as a loaded document with the mcp key normalized to mcp.servers.
No experimental.policies, enterprise, or provider-filter entries are present that could explain a hard deny.
Workaround: none found. Config-side changes make no difference, so MCP servers appear unusable on Windows builds of 2.0.14.

Additional repro data (Windows, opencode v2.0.12) — same symptoms confirmed on opencode v2.0.12 (npm @opencode/cli), extending the affected range below your 2.0.14. Extra findings beyond the OP:

Project-level configs fail too, not just global. Minimal temp project dir with a single server (opencode.json at cwd) → mcp list still prints No MCP servers configured, for both V1-flat (mcp: {name: {...}}) and V2-native (mcp: {servers: {...}}) shapes.
mcp add's own output is invisible. opencode mcp add <name> -- <cmd> writes a valid V2 entry to the project config (file contents verified) and the immediately following mcp list still reports zero. So content, authoring, normalization flags, and V1-vs-V2 shape are all ruled out — every path lands on an empty resolved view.
debug config is healthy in every case: the document layer shows all servers converted under mcp.servers (e.g. {"type":"local","command":[...],"disabled":true}), while the runtime consumers (configuredServers in cli/cmd/mcp.ts, MCP.status() in mcp/index.ts, GET /api/mcp) see nothing. Resolved-view shape is not externally observable — it is either still nested ({servers} iterated as a flat map yields one non-type key) or the mcp key is dropped entirely during merge; both produce identical symptoms.
TUI impact: the MCP dialog (fed by the mcp.status() sync) renders an empty list with the same payload, so the MCP picker/toggle UI is unusable on Windows as well — this was the user-visible symptom that started the investigation here.
Release-window analysis: path-filtered commit history on both dev and the v2 release branch shows no commits since 2026-09-19 touching packages/opencode/src/mcp/index.ts, packages/opencode/src/cli/cmd/mcp.ts, packages/opencode/src/config/config.ts, or packages/opencode/src/config/v2-compat.ts → 2.0.15/2.0.16 almost certainly still carry this.

Windows-specific hypothesis worth checking: the resolved config may be stored/looked up under a location key with mismatched path normalization (e.g. C:\Users\... from the location layer vs C:/Users/... from path.win32 APIs, or drive-letter casing). A map lookup miss would yield an empty/undefined config exactly for the runtime consumers while documents (read per file path) stay correct — and on Linux the two key forms coincide, which would explain the cross-OS contrast in the OP.

Environment: Windows, isolated v2.0.12 alongside v1.18.32, shared ~/.config/opencode/opencode.json.

This is not Windows-specific. Reproducing the same symptom set on macOS 27.0 (Apple Silicon), opencode v2.0.22, which contradicts the "same config shape on Linux lists and connects the servers normally" scoping in the report.

Identical signature to yours:

opencode debug config reports the MCP servers correctly — both of mine appear under mcp, normalised, with disabled: false.
opencode mcp list prints No MCP servers configured.
Providers defined in the same file resolve fine; a custom OpenAI-compatible provider in that config works, so the file is being read.
The running agent has zero MCP tools. Asked directly, it answers that the only tools it can call are the tools.opencode.* namespace ones (list_mcp_resources, models, read_mcp_resource, session_move, session_rename), and tools.opencode.list_mcp_resources({}) returns nothing.

Two extra data points that may help narrow it:

Transport makes no difference. One of my two servers is remote HTTP ({"type":"remote","url":"http://127.0.0.1:…/mcp"}), the other local stdio ({"type":"local","command":[...]}). Neither reaches the agent. The HTTP one is independently confirmed healthy — other clients on the same machine connect to it and call its tools right now.
Config shape makes no difference either. I tried both the flat mcp.<name> form and the nested mcp.servers.<name> form that opencode mcp add --global writes (see MCP: invalid location of mcp when used --global #49904), with an agent run after each. Zero tools either way. So this is not the --global write-location issue wearing a disguise.

One suggestion on diagnosis, from the outside: debug config and mcp list disagreeing is itself the most useful signal here, and it points at the gap between parsing the config and the service registering from it. I had initially written mcp list off as the unreliable one and debug config as ground truth — testing at the agent level showed the opposite, that mcp list accurately reports what the runtime holds while debug config only echoes the parsed file. If that framing is right, anyone trusting debug config will believe their MCP setup works when no tool is reachable, which is a quiet way to lose a feature.

Happy to run anything specific against this install — it reproduces every time, no intermittency here.

i've seen this bug a few times too (on Mac). it's very confusing. i'd appreciate a fix being merged for this

Adding measured data points from v2.1.4 on Windows 11 (2026-10-24) in case they help pin the Windows-service half. All from a setup with 30 entries under the global mcp.servers:

No per-server diagnostic route. opencode debug (v2.1.4) exposes agents, config, heap-dump, paths - there is still no mcp/per-server subcommand, while third-party install guides tell users to run opencode mcp debug <name>. opencode mcp itself lists only list, add, auth, logout.
A failing server's real cause is cut off. mcp list truncated a Python-based stdio server's error right after the first exception block (...exited with code 1: _run_module_as_main), while the actual cause - a UnicodeEncodeError from a cp1252 banner write in the server - only became visible when we ran the same binary manually outside OpenCode. Seeing the last N lines (chained cause intact) would have saved that round trip.
CLI visibility vs runtime visibility is unstable across the same config. In one run today opencode mcp list answered No MCP servers configured while the running session was serving those same global-config servers; a later run listed them all as connected. Recording it as an observation, not a root cause - it may be the same Windows-service registration gap this issue tracks.
Placeholder syntax has three dialects and no validation surface: {env:VAR} (OpenCode config), ${env:VAR} (.vscode/mcp.json), ${VAR} (portable .mcp.json). A wrong one fails only at connect time (for us: HTTP 400 Authorization header is badly formatted).

Posting these here rather than filing a separate issue, since the CLI/global-config diagnosability gap is this tracker; the UX asks from #58243 (per-server output panel, placeholder prompts + keystore, config editor) are being split out separately.

Navigation Menu

Repository navigation

mcp: Windows service registers zero MCP servers from global config #50710

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

mcp: Windows service registers zero MCP servers from global config #50710

Description

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Activity

BazzaGee commented on Sep 25, 2026

djbclark commented on Oct 3, 2026

mathew-cf commented on Oct 9, 2026

arin8513 commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions