MCP VS Code MCP server

MCP VS Code

MCP VS Code runs a self-hosted Code OSS/OpenVSCode workbench beside an MCP server so the human and the model operate the same workspace, open editors, diagnostics, commands, extensions, and terminal sessions. This is not remote control of a separately installed desktop VS Code. Supported distributions carry their own OpenVSCode runtime and bridge extension. Microsoft-hosted vscode.dev is not used because it disallows framing.

The caveman picture

There are four pieces:

1. The MCP host—for example FLUJO or Claude Desktop—owns the outer sandbox and its security policy.
2. The small MCP App document asks the host for permission to reach and, in default mode, frame the workbench origin.
3. The mcp-vscode gateway exposes only the routes needed to reach the private runtime.
4. The OpenVSCode process runs on the MCP server machine, binds to loopback, opens the configured workspace, and connects its bridge extension back to the MCP server.

flowchart LR
    H["MCP host"] <-->|"stdio or Streamable HTTPS"| S["mcp-vscode server"]
    H --> A["sandboxed MCP App"]

    A -->|"default: allowed frameDomains"| I["OpenVSCode iframe"]
    A <-->|"opt-in: authenticated /stream WebSocket"| C["pixel canvas"]
    A -->|"honest fallback: openLink"| X["separate browser tab"]

    I --> G["browser-reachable gateway origin"]
    X --> G
    C <-->|"JPEG frames + input"| B["server-side system Chromium"]
    B --> O["loopback OpenVSCode"]
    G --> O
    O <-->|"authenticated /bridge WebSocket"| S
    S --> W["confined workspace and PTYs"]
    O --> W

The default iframe and browser-tab paths deliver OpenVSCode directly. Experimental streaming launches an existing Edge, Chrome, or Chromium on the server, points it at that same OpenVSCode runtime, and transports its pixels and user input. The canvas is a remote display, not another editor implementation.

Rendering modes

probing is a temporary UI state, not a renderer.

Default behavior: iframe or browser

With no render-mode environment variable, the App:

1. waits for the bundled OpenVSCode runtime;
2. compares the workbench origin with the effective frameDomains reported by the host when that information is available;
3. skips iframe navigation immediately when the host explicitly denied the origin;
4. otherwise navigates the iframe and waits for the injected mcp-vscode:workbench-alive message;
5. commits embedded only after that positive signal; or
6. shows the browser card with the exact policy, network, or runtime reason.

A CSP-blocked iframe can emit neither a useful load nor error event, so a plain iframe event is not treated as success. The liveness timeout prevents a permanent blank view.

An MCP server's CSP declaration is a permission request, not a way to overrule the host. A host may approve it, restrict it, or deny it. CORS headers on mcp-vscode cannot repair a frame-src decision made by the outer host.

Experimental streaming

Set:

MCP_VSCODE_RENDER_MODE=stream

Shortened. The full README is on GitHub.