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

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.

我这边也出现了这种问题

我也是

$ 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.

@semidark

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.

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:

Home directory — called from home.tsx, sidebar-project.tsx, sidebar-workspace.tsx, notification.tsx with { bootstrap: false } — no mcp: true
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:

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")
Or ensure directory-sync.ts mounts and calls child(directory, { mcp: true }) before bootstrapInstance() reads the flag

Same issue happening on macOS...

Fixed by #30220

Navigation Menu

Repository navigation

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

Summary

Environment

Actual Behavior

Screenshots

Expected Behavior

CLI Result

Additional Debugging Performed

Debug Command Notes

Hypothesis

Root Cause Analysis — PR #28937 Race Condition

The mechanism

Suggested fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Actual Behavior

Screenshots

Expected Behavior

CLI Result

Additional Debugging Performed

Debug Command Notes

Hypothesis

Activity

ShimizuSakukoi commented on May 31, 2026

jjserenity commented on May 31, 2026

semidark commented on May 31, 2026

WhiteGiverMa commented on May 31, 2026

gabriel-ferraresi commented on May 31, 2026

Root Cause Analysis — PR #28937 Race Condition

The mechanism

Suggested fix

anonfaded commented on May 31, 2026

Hona commented on Jun 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions