[BUG] VS Code extension: prompts from a remote (HTTP) MCP server never appear in the slash-command picker — `commands_changed` is stored but never read

Status Open
Reported on v2.1.232
Maintainer reply None cached
Activity 0 comments · opened Aug 31, 2026

What's Wrong?

In the VS Code extension, prompts served by a remote HTTP MCP server (OAuth-protected, ~270 ms RTT from here) never show up in the / autocomplete, while prompts from a local stdio server do.

The cause is in how the extension builds its command list:

  1. The extension takes the commands array from the reply to the SDK control request initialize (either the first session's, or a separate "config probe" claude process's — loadConfig() → spawnConfigProbe()), stores it, and returns the cached value from then on. Only a Claude account login/logout invalidates it (invalidateConfigCache() has four call sites, all login/logout).
  2. The CLI answers that initialize request roughly 0.8 s after it starts connecting MCP servers. A local stdio server is connected by then; a remote server that needs a TCP + TLS + initialize + initialized + SSE round trip over the internet is not, so its prompts are absent from the reply.
  3. The CLI later emits system/commands_changed, whose own schema says "Fire-and-forget push of the full slash-command list after a mid-session change … Clients should replace their cached command list with this payload". The extension stores it (this.latestCommands = e.commands) and exposes it through supportedCommands() — return this.latestCommands ?? $ — but nothing in the bundle ever calls supportedCommands(). The webview's picker reads claudeConfig.commands, i.e. the original snapshot.

So the picker is a one-shot snapshot taken at the exact moment a remote server cannot yet have connected, and the update designed to correct it is dropped on the floor. Reloading the window rebuilds the snapshot and loses the same race again.

The prompts do work when typed in full; only autocomplete misses them.

What Should Happen?

Either of:

  • the extension applies commands_changed to the list the picker reads (its supportedCommands() already returns latestCommands ?? initial; the picker just doesn't use it), or
  • the initialize reply waits for MCP servers the way system/init does (bounded by MCP_TIMEOUT, as it already is elsewhere).

Error Messages/Logs

No error anywhere — every component reports success. Relevant excerpts:

# claude.exe 2.1.232, commands_changed schema (strings in the binary)
Fire-and-forget push of the full slash-command list after a mid-session change
(e.g. skills discovered dynamically as the agent works in a subdirectory).
Clients should replace their cached command list with this payload

# extension.js 2.1.251
if($.type==="system"&&$.subtype==="commands_changed"&&Array.isArray($.commands))this.latestCommands=$.commands;
...
async supportedCommands(){let{commands:$}=await this.initialization;return this.latestCommands??$}
# ^ "supportedCommands" occurs exactly once in the bundle — its definition.

# webview/index.js 2.1.251
slashCommands=w2(()=>{return this.comms.connection.value?.claudeConfig.value?.commands});

# mcp-logs-<remote server>/2026-08-31T12-52-10-718Z.jsonl
12:52:21.230 Initializing HTTP transport to https://<server>/mcp/
12:52:22.689 Successfully connected (transport: http) in 1459ms

Steps to Reproduce

  1. Configure one local stdio MCP server that serves prompts and one remote HTTP MCP server that serves prompts, where the remote one takes more than ~1 s to connect (any server across an ocean will).
  2. Open the Claude Code panel in VS Code and type / — the local server's prompts are listed, the remote server's are not.
  3. Wait until the remote server reports connected (its tools become callable), reopen the picker — still absent. Reload the window — still absent.
  4. Outside VS Code, run claude --input-format stream-json --output-format stream-json --verbose, send {"type":"control_request","request_id":"1","request":{"subtype":"initialize"}} and compare the reply's commands with the system/init message's slash_commands after sending a user message: the remote server's prompts are in the second and not the first.

Claude Model

N/A — this is client behaviour before any model call.

Is this a regression?

Unknown

Last Working Version

Unknown

Claude Code Version

CLI 2.1.232; VS Code extension 2.1.251; VS Code 1.106.0

Platform

VS Code extension

Operating System

Windows 11 (10.0.26200)

Terminal/Shell

Git Bash (for the reproduction commands); the bug is in the extension, not the terminal

Additional Context

The same server's prompts appear in the CLI's own / menu (as /<server>:<prompt>), which suggests the interactive CLI consumes commands_changed while the extension does not.

Related, not duplicates: #30738 (closed not-planned in April, "MCP prompts not exposed as slash commands in the extension" — they are now, the local server's prompt is listed, so this is a different defect), #66099 (auto-closed as its duplicate and locked, with "file a new issue and reference this one"), #75234 (the open Desktop-app sibling).

View original on GitHub ↗