MCP servers remain "Disconnected" on Windows/WSL despite valid JSON-RPC responses via stdio/HTTP #25992

What happened?

Environment:

• OS: Windows 10/11
• WSL: Ubuntu-22.04 (Docker Desktop backend)
• Gemini CLI Version: 0.39.1
• Node.js Version: v24.11.0

Description:
I am experiencing a persistent issue where MCP servers configured to run through wsl.exe are always reported as Disconnected by the Gemini
CLI, even though the commands are confirmed to be functional when executed manually.

Steps to Reproduce:

1. Configure a server via WSL/Docker:
   gemini mcp add wikipedia -s user "C:\Windows\System32\wsl.exe -d Ubuntu-22.04 -- docker run -i --rm mcp/wikipedia-mcp"

2. Check status:
   Run /mcp inside a session or gemini mcp list.
   Actual Result: ✗ wikipedia: ... (stdio) - Disconnected

3. Manual verification (Proof of health):
   Piping an initialization header directly to the same command works perfectly:
   echo '{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"capabilities": {}, "clientInfo": {"name": "test", "version":
   "1.0"}, "protocolVersion": "2024-11-05"}}' | C:\Windows\System32\wsl.exe -d Ubuntu-22.04 -- docker run -i --rm mcp/wikipedia-mcp
   Result: The server returns a valid JSON-RPC response. This confirms the issue is within the Gemini CLI's process management or stdio
   stream handling on Windows.

Additional Findings:

• Argument Parsing: The gemini mcp add command parser appears to prematurely consume flags like -d or -- even when they are inside quotes.
• HTTP Transport: Even when running the MCP server as an HTTP service inside WSL (verified via curl), Gemini CLI fails to connect using -t
  http.
• Trust Loop: The CLI consistently reports the directory as "untrusted" even after running gemini trust.

What did you expect to happen?

I expected the Gemini CLI to successfully establish a stable stdio connection with the MCP server. Once configured, the server status
should appear as 'Connected' in the /mcp list, and its tools should be fully accessible to the AI agent during the session. Additionally, I
expected that after running gemini trust, the directory would be recognized as trusted and its specific MCP configurations would be applied
correctly."

Tradução (para seu conhecimento):
"Eu esperava que o Gemini CLI estabelecesse com sucesso uma conexão estável de stdio com o servidor MCP. Uma vez configurado, o status do
servidor deveria aparecer como 'Conectado' na lista do /mcp, e suas ferramentas deveriam estar totalmente acessíveis para o agente de IA
durante a sessão. Além disso, eu esperava que após rodar o 'gemini trust', o diretório fosse reconhecido como confiável e suas configurações
específicas de MCP fossem aplicadas corretamente.

Client information

1 > /about (System Info)
2 Gemini CLI Version: 0.39.1
3 Node.js Version: v24.11.0
4 OS: win32 (Windows 10/11)
5 CWD: C:\Users\marco\Development
6 Trust Status: Untrusted (Project settings ignored)
7 MCP Servers Configured: 4 (user scope)

Login information

Logged in via Google Account using the /auth flow. Account plan: Gemini Code Assist in Google One AI Pro.

Anything else we need to know?

The same MCP servers (Wolfram Alpha and Wikipedia) are confirmed to be working perfectly within the same WSL environment when used with
Claude Code. The issue seems specific to how Gemini CLI handles the stdio/HTTP lifecycle on the Windows host.

Also, there is a persistent 'Untrusted folder' warning that appears every time a new session starts, even after executing gemini trust
multiple times. This suggests a potential issue with how settings and permissions are being persisted or read from
%USERPROFILE%.gemini\settings.json on Windows.