Desktop /MCP panel shows 0/0 while CLI lists connected MCP servers

[Harrymeit]

Summary

OpenCode Desktop shows Enabled 0 / 0 in the /MCP panel even though the CLI can list and connect to configured MCP servers. This looks like the Desktop sidecar/live sync state is not populating sync.data.mcp, while the CLI MCP registry/config resolution works correctly.

Environment

• OS: Windows
• OpenCode Desktop version: 1.15.13
• Desktop update channel: latest
• Desktop auto-updater result: no update available; latest version also reported as 1.15.13
• Config file in use: C:\Users\taiyu\.config\opencode\opencode.jsonc
• CLI shim: C:\Users\taiyu\AppData\Roaming\npm\opencode.cmd

Actual Behavior

In OpenCode Desktop, opening /MCP shows:

Enabled 0 / 0

Screenshots

Screenshot 1 shows the CLI/TUI MCP selector resolving the configured MCP servers correctly. It lists servers such as ast_grep, chrome-devtools, context7, grep_app, lsp, pencil, supabase, supabase:supabase, and websearch. Most entries are connected and Enabled; only the duplicate supabase:supabase entry is disabled/needs auth.

Screenshot 2 shows the Desktop /MCP modal for the same setup. The modal reports 0 of 0 enabled and displays No MCPs configured, even though the CLI/TUI view shows the MCP servers above.

The Desktop UI code appears to render this from something equivalent to:

Object.entries(sync.data.mcp ?? {})

So the UI is receiving an empty MCP state object, not merely hiding configured servers.

Expected Behavior

The Desktop /MCP panel should show the same MCP servers that the CLI resolves and reports via opencode mcp list.

CLI Result

Running:

C:\Users\taiyu\AppData\Roaming\npm\opencode.cmd mcp list

shows 9 MCP servers total:

websearch          connected
context7           connected
grep_app           connected
lsp                connected
ast_grep           connected
pencil             connected
supabase           connected (OAuth)
chrome-devtools    connected
supabase:supabase  needs authentication

So the CLI side can resolve the config and MCP registry successfully. 8 of the 9 servers are usable; the remaining one is intentionally skipped because it is a duplicate Supabase entry that still needs authentication.

Additional Debugging Performed

I tried the minimal Desktop cache reset:

Get-Process | Where-Object { $_.ProcessName -match 'OpenCode' } | Stop-Process -Force
Remove-Item -LiteralPath "$env:APPDATA\ai.opencode.desktop\opencode.global.dat" -Force
& "$env:LOCALAPPDATA\Programs\@opencode-aidesktop\OpenCode.exe"

After restart, opencode.global.dat was regenerated, but searching the regenerated file showed no MCP-related state:

HasLiteralMcp : False
HasWebsearch  : False
HasSupabase   : False

Desktop logs show the sidecar starting successfully:

app starting { version: '1.15.13', packaged: true }
sidecar connection started { url: 'http://127.0.0.1:<port>' }
spawning sidecar { url: 'http://127.0.0.1:<port>' }
server ready { url: 'http://127.0.0.1:<port>' }
no update available { reason: 'provider returned no newer version' }

No MCP-specific error appears in the Desktop logs. The only observed renderer/server messages were unrelated PTY/ResizeObserver warnings.

Debug Command Notes

• opencode mcp debug supabase reports OAuth is authenticated and ends with connection successful.
• websearch and grep_app report OAuth explicitly disabled, which seems expected.
• Local/non-remote servers such as lsp, ast_grep, pencil, and chrome-devtools report that OAuth debug is not applicable, while mcp list still shows them connected.
• context7 is shown as connected by mcp list, though mcp debug context7 timed out in this environment.

Hypothesis

This appears to be a Desktop 1.15.13 sidecar/UI sync bug: CLI MCP registry/config resolution works, but the Desktop live sync object does not populate sync.data.mcp, causing /MCP to render 0 / 0.

[ShimizuSakukoi]

我这边也出现了这种问题

[jjserenity]

我也是

[semidark]

$ opencode upgrade 1.15.12

                                   ▄
  █▀▀█ █▀▀█ █▀▀█ █▀▀▄ █▀▀▀ █▀▀█ █▀▀█ █▀▀█
  █  █ █  █ █▀▀▀ █  █ █    █  █ █  █ █▀▀▀
  ▀▀▀▀ █▀▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀▀▀

┌  Upgrade
│
●  Using method: curl
│
●  From 1.15.13 → 1.15.12
│
◇  Upgrade complete
│
└  Done

Did a downgrade to the latest patch version 1.15.12 and now the MCP servers are back.

[WhiteGiverMa]

Confirming this on OpenCode Desktop 1.15.13 + Windows as well.

Same symptoms: /MCP panel shows Enabled 0 / 0 with No MCPs configured, even though the CLI (opencode mcp list) correctly resolves all MCP servers as connected.

This is Desktop-specific — not a WezTerm/terminal rendering issue. The TUI side (CLI) sees the MCP servers fine; only the Desktop panel is blank.

Downgrading to 1.15.12 restored MCP visibility, as confirmed by @semidark above. Seems like a clear regression in 1.15.13.

[gabriel-ferraresi]

Root Cause Analysis — PR #28937 Race Condition

I've traced this to a race condition introduced by PR #28937 (fix(app): start MCP servers only for open directories), which shipped in v1.15.13.

The mechanism

PR #28937 added an mcp: boolean flag to ChildOptions and bootstrapDirectory(). The MCP query in child-store.ts starts disabled (createSignal(false)) and only enables when enableMcp() is called.

The Desktop bootstraps directories in two passes:

1. Home directory — called from home.tsx, sidebar-project.tsx, sidebar-workspace.tsx, notification.tsx with { bootstrap: false } — no mcp: true
2. Project directory — called from directory-sync.ts with { mcp: true }

The race: bootstrapDirectory() reads children.mcp(key) synchronously at call time. But enableMcp() is called asynchronously when directory-sync.ts mounts. If bootstrap completes before the directory-sync context calls child(directory, { mcp: true }), the MCP queries (mcp.status(), command.list()) are permanently skipped for that bootstrap cycle.

This explains why:

• Downgrading to 1.15.12 works — PR fix(app): start MCP servers only for open directories #28937 didn't exist yet
• CLI works — CLI doesn't use the child() / enableMcp() flow
• MCPs are functional but invisible — the servers start via the sidecar/plugin, but the Desktop UI never fetches mcp.status() because the query was gated by the mcpEnabled signal

Suggested fix

Either:

1. Have enableMcp() trigger a re-fetch of MCP queries when called after bootstrap has already completed (the onMcp callback already exists for this but only fires when status !== "loading")
2. Or ensure directory-sync.ts mounts and calls child(directory, { mcp: true }) before bootstrapInstance() reads the flag

[anonfaded]

Same issue happening on macOS...