gemini-cli - 💡(How to fix) Fix [WSL2][Critical] Gemini 3.1 Pro cannot self-diagnose its own WSL configuration failures — Claude Sonnet 4.6 fixed in minutes what 3+ weeks of Gemini CLI could not [2 comments, 1 participants]

Environment

• OS: Windows 10 Host / Ubuntu 24.04 (WSL2)
• Gemini CLI: v0.40.0
• Model: gemini-3.1-pro-preview
• Shell: bash (WSL2)
• Comparison baseline: Claude Sonnet 4.6 in Antigravity IDE (same machine, same WSL environment)

Summary

After nearly one month of daily use of gemini-3.1-pro-preview via Gemini CLI in a WSL2 environment, I am filing this issue to document a systemic, reproducible failure pattern: the model is fundamentally incapable of self-diagnosing its own WSL configuration issues, and consistently takes destructive or incorrect actions when confronted with WSL-specific bugs — including bugs caused directly by Gemini CLI's own behavior.

In contrast, Claude Sonnet 4.6 running in the same environment (Antigravity IDE, same WSL2 instance) diagnosed and permanently fixed the same issues in a single session. This is not a one-time fluke. This is a consistent, measurable pattern over weeks of parallel testing.

The Bugs That Persisted For Weeks (That Gemini 3.1 Pro Could Not Fix)

Bug 1: MCP Servers Permanently Disconnected — Root Cause: bunx -y Startup Timeout

What actually happened: Gemini CLI's MCP server configuration used bunx -y <package> to launch MCP servers. This approach downloads the package at startup time. In WSL2, Bun's install cache is treated as a network drive, triggering this warning:

warn: Slow filesystem detected. If /home/user/.bun/install/cache is a network drive,
consider setting $BUN_INSTALL_CACHE_DIR to a local folder.

This 5–15 second startup delay caused Gemini CLI's MCP connection timeout (~5 seconds) to be exceeded, resulting in the following MCPs being permanently disconnected on every startup:

• memory
• chrome-devtools
• sequential-thinking
• google-maps-platform-code-assist

What Gemini 3.1 Pro did instead: For weeks, the model repeatedly:

1. Suggested restarting the MCP servers (which doesn't fix the root cause)
2. Tried to run omni_enforcer.py which ran for 40+ minutes and caused another crash
3. Suggested port conflicts as the cause (incorrect)
4. Never identified bunx -y startup latency as the root cause

What Claude Sonnet 4.6 did: Immediately identified that bunx -y causes download-on-startup behavior, cross-referenced the startup logs, identified the exact timeout threshold, and changed all affected MCPs to use bun <absolute-path> instead — fixing the issue in under 5 minutes.

The fix (trivially simple, took 2 minutes to implement):

// BEFORE (broken)
"memory": { "command": "bunx", "args": ["-y", "@modelcontextprotocol/server-memory"] }

// AFTER (fixed)
"memory": { "command": "bun", "args": ["/home/user/.npm-global/lib/node_modules/@modelcontextprotocol/server-memory/dist/index.js"] }

Bug 2: Zombie Process Cascade Causing Full MCP Blackout — Root Cause: Model's Own Suggestion

What actually happened: The model itself previously suggested adding a gemini-yolo() bash function that ran npm install -g @google/gemini-cli@latest on every startup:

gemini-yolo() {
    npm install -g @google/gemini-cli@latest --silent
    gemini --yolo "$@"
}

Over time, this created a cascade:

1. npm install hangs in slow WSL network conditions
2. User opens new terminal, runs gemini again
3. Another npm install starts hanging
4. Repeat → 9 simultaneous Gemini CLI Node.js processes found in memory

Result: All 12 MCP servers showed as Disconnected because zombie processes had locked ports, memory, and file descriptors.

What Gemini 3.1 Pro did when presented with this:

• Suggested "run /mcp list to diagnose" (not helpful)
• Did not identify the zombie processes as the source
• Did not identify the gemini-yolo() function (which it had previously written) as the root cause
• Ran pgrep incorrectly, never actually confirmed process count

What Claude Sonnet 4.6 did:

$ pgrep -a gemini | wc -l
# → 18 (9 pairs of wrapper + Node process)

Immediately identified zombie cascade → killed all processes → identified gemini-yolo() as the cause → disabled it permanently → added a Zombie Guard to the gemini() function.

Bug 3: Model Repeatedly Misdiagnosed WSL as "Deadlocked" When It Was Functioning Normally

Previously filed as issue #26154. The model, when encountering a simple network timeout or missing mount point, would declare a "critical 9P kernel deadlock" and instruct the user to run wsl --shutdown — terminating all running processes unnecessarily. This happened multiple times over the month.

This is the inverse problem: not only can the model not find real bugs, it also invents catastrophic failures when none exist.

Comparative Performance Summary

This is not a model comparison issue filed in bad faith. This is a documented, reproducible pattern observed across hundreds of interactions over nearly one month. The same WSL2 environment, the same machine, the same user — but consistently different outcomes depending on which model is executing.

What This Means for Gemini CLI Users on WSL

1. Gemini CLI's default MCP configuration ships with bunx -y commands that are inherently broken in WSL2 due to Bun's slow filesystem detection treating WSL's virtual filesystem as a network drive.

2. The model embedded in Gemini CLI cannot reliably debug Gemini CLI's own configuration, which means users are left without recourse when the tool breaks itself.

3. The Zombie Guard and bunx fix are not discoverable — users have no way of knowing about these WSL-specific failure modes without weeks of debugging.

Requested Actions

1. Fix the default MCP configuration to use pre-installed absolute paths instead of bunx -y for all default MCP servers
2. Add WSL-specific startup documentation warning about bunx -y and Bun's slow filesystem behavior
3. Add a process guard that prevents multiple Gemini CLI instances from starting simultaneously
4. Improve model system prompting with WSL-specific diagnostic patterns so the model can recognize these failure modes
5. Add a gemini doctor-style diagnostic command that checks:
   • Number of running Gemini CLI processes
   • MCP binary paths (absolute vs. bunx)
   • WSL filesystem type detection
   • Current path (reject /mnt/c/ with clear error)

Related Issues

• #26091 — 9P Protocol Deadlock
• #26114 — Large paste premature execution
• #26117 — Comprehensive reliability failure report
• #26154 — Model over-escalates to deadlock
• #25203 — WSL2 9P hanging/OOM