[BUG] Regression (v2.1.212): VS Code extension hangs at "Connecting…" for a healthy stdio MCP server on Windows 11 — cmd /c fixes it

Status Open
Reported on v2.1.212
Maintainer reply None cached
Activity 2 comments · opened Jul 17, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary

After ~a week of working reliably, the VS Code extension suddenly hangs at
"Connecting…" for a healthy stdio MCP server (postgres-mcp) on Windows 11 and
never connects. The database, credentials, network, and MCP server are all
verified healthy — the server completes the MCP initialize handshake correctly
when run from the terminal. The failure is entirely on the extension side and
coincides with the extension auto-updating to v2.1.212. Wrapping the launch
in cmd /c (+ PYTHONUNBUFFERED=1) restores a normal ✓ Connected state.

Environment

  • Claude Code VS Code extension: anthropic.claude-code v2.1.212 (auto-updated ~14h before onset)
  • OS: Windows 11
  • MCP server: postgres-mcp (crystaldba) v0.3.0, global Python 3.12
  • Deps in that env: mcp 1.28.1, pydantic 2.13.4
  • Transport: stdio, launched from user-scope mcpServers in ~/.claude.json

Actual behavior

Extension MCP panel shows postgres — Connecting… indefinitely. Tools never
load; DB-dependent requests stall. A full quit/reopen of VS Code (and the app)
does not help.

Expected behavior

The server connects as it did before the update — and as it still does from the
terminal.

Evidence the server / DB are healthy (all pass)

  • Test-NetConnection localhost -Port 5432True (also 127.0.0.1)
  • Postgres listening on :: and 0.0.0.0 (all interfaces)
  • Direct psql connect with the exact MCP DSN returns instantly:

select now() → OK, current_user = the MCP's role

  • Running the server binary manually logs:

Successfully connected to database and initialized connection pool

  • Feeding a real initialize JSON-RPC message to the server over stdio returns

a correct result with serverInfo — i.e. the handshake works standalone

What Should Happen?

Workaround that fixed it

Changing the server config from launching the .exe directly to wrapping it in
cmd /c, and adding PYTHONUNBUFFERED=1:

"postgres": {
"command": "cmd",
"args": ["/c", "C:/.../Scripts/postgres-mcp.exe", "--access-mode=unrestricted"],
"env": { "DATABASE_URI": "postgresql://<user>:<pw>@localhost:5432/<db>", "PYTHONUNBUFFERED": "1" }
}

The previous config used "command": "<...>/postgres-mcp.exe" directly (no
wrapper), which had worked for ~a week until the 2.1.212 update.

Related

  • #22706 — MCP servers not connecting on Windows 11 (same Windows stdio class; cmd /c workaround)
  • #25751 — VS Code extension silently abandoning a healthy stdio server (closed as duplicate; reload-window workaround)

Suggested

The extension appears to have regressed Windows stdio spawn handling and/or
shortened the startup handshake timeout in 2.1.212, such that a bare-exe stdio
server no longer connects. Consider restoring the prior spawn behavior (or
documenting a cmd /c requirement on Windows), and surfacing a connection error
instead of an indefinite "Connecting…".

Error Messages/Logs

Connecting to a database with MCP would hang at "connecting" indefinitely.

psql: error: connection to server at "127.0.0.1", port 5432 failed:
FATAL:  password authentication failed for user "postgres"

{"method":"notifications/message","params":{"level":"error","logger":"mcp.server.exception_handler","data":"Internal Server Error"},"jsonrpc":"2.0"}

ERROR  Received exception from stream: 1 validation error for JSONRPCMessage
       Invalid JSON: EOF while parsing a value at line 2 column 0
       [type=json_invalid, input_value='\n', input_type=str]

Steps to Reproduce

Steps to reproduce

  1. On Windows 11, install a Python stdio MCP server into a global Python

install — e.g. pip install postgres-mcp into Python 3.12 — so it pulls the
current mcp (1.28.1) and pydantic (2.13.4).

  1. Make sure the backing service is up and reachable (Postgres listening on

localhost:5432).

  1. Add the server to the user scope of ~/.claude.json, launching the

executable directly (no wrapper) — this is the config that worked prior
to 2.1.212:

"mcpServers": {
"postgres": {
"command": "C:\\Users\\<you>\\AppData\\Local\\Programs\\Python\\Python312\\Scripts\\postgres-mcp.exe",
"args": ["--access-mode=unrestricted"],
"env": { "DATABASE_URI": "postgresql://<user>:<pw>@localhost:5432/<db>" }
}
}

  1. Open a workspace in VS Code with the Claude Code extension v2.1.212.
  2. Open the MCP servers panel.

Result: postgres sits at "Connecting…" indefinitely; tools never load;
DB-dependent requests stall. Fully quitting and reopening VS Code does not help.

Confirm the server/DB are healthy (isolates the fault to the extension)

  • Test-NetConnection localhost -Port 5432True
  • Direct connect with the exact DSN returns instantly:

psql "postgresql://<user>:<pw>@localhost:5432/<db>" -c "select now()"

  • Feed a real initialize over stdio and confirm a valid response:

$env:DATABASE_URI="postgresql://<user>:<pw>@localhost:5432/<db>"
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' | & "C:\...\postgres-mcp.exe" --access-mode=unrestricted

→ server returns {"jsonrpc":"2.0","id":1,"result":{...,"serverInfo":{...}}}

Confirm the fix

Change command to cmd with args: ["/c", "<exe path>", "--access-mode=unrestricted"],
add "PYTHONUNBUFFERED": "1", save, and run Developer: Reload Window
panel shows ✓ Connected.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Version from 15 hours ago.

Claude Code Version

Currently 2.1.212 that dropped 1 hour ago

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗