[Bug Report] Gemini CLI on WSL has critical MCP config, file-path, and model reliability issues — Claude Sonnet 4.6 consistently outperforms Gemini 3.1 Pro in the same WSL environment

Summary

After extensive real-world troubleshooting over multiple days using Gemini CLI v0.39.1 inside WSL2 (Ubuntu 24.04) on Windows 11, I am reporting a cluster of severe, reproducible bugs that severely degrade the developer experience. Many of these issues are not present when using Claude Sonnet 4.6 (via Antigravity/API) in the same WSL environment — strongly suggesting they are caused by model-side reasoning failures specific to how Gemini 3.1 Pro handles the WSL+Windows dual-path environment.

---

Environment

• OS: Windows 11
• Shell: WSL2 (Ubuntu 24.04)
• Gemini CLI version: v0.39.1
• Account type: Google One AI Ultra (Gemini Code Assist)
• Starting directory: /mnt/c/Users/Charles Lee (Windows home, mounted in WSL)

---

Bug #1: Global mcp.json is never read — only 2 of 12 MCP servers load

Steps to Reproduce

1. Run gemini --yolo from any directory inside WSL.
2. Type /mcp inside the CLI.

Expected

All configured MCP servers (12 total) load correctly.

Actual

Only 2 servers load (gcloud 🔴 Disconnected, google-workspace 🟢 Ready). All others are silently ignored.

Root Cause (diagnosed manually)

The mcp.json was being written by our sync tool to /mnt/c/Users/Charles Lee/.gemini/mcp.json (Windows-side path). However, Gemini CLI, running under WSL, reads MCP configuration from the Linux home directory: /home/<user>/.gemini/mcp.json.

This discrepancy is never documented and Gemini CLI gives zero error, warning, or diagnostic output about the missing global config. Running /mcp list only shows "MCP issues detected" with no actionable details.

Fix Applied (by user)

We had to manually diagnose this and patch our sync script to write to both /mnt/c/Users/.gemini/mcp.json AND ~/.gemini/mcp.json.

Requested Fix

• Gemini CLI should search both the Windows user profile .gemini/ (when running under WSL) and the Linux home ~/.gemini/ for mcp.json.
• OR: Document clearly which path is authoritative under WSL, and emit a clear warning when a config file is found at the wrong path.

---

Bug #2: C:\.git root-level git pollution — Gemini model recommends git init at Windows root

Steps to Reproduce

1. Ask Gemini CLI (model: Gemini 3.1 Pro) to "sync all projects to GitHub".
2. Observe model behavior.

Actual

The model issued a git init (or equivalent ginit alias expansion) from the root /mnt/c/ path, effectively creating a .git directory at the root of the entire C: drive. This caused every subdirectory on the C: drive to become part of the same Git repository, leading to catastrophic cross-project file contamination: unrelated project files from dozens of different directories were staged and committed together.

Expected

The model should always validate the current working directory before running git init and refuse to run it in a root or near-root path (e.g., /mnt/c/, /, ~ unless a .git doesn't already exist there and it's the intended project root).

Impact

• Multiple unrelated projects were contaminated and incorrectly committed.
• The C:\.git had to be manually renamed to C:\.git_backup_corrupted to neutralize the damage.
• All Git history for affected projects became ambiguous.

---

Bug #3: Model fails to reason about WSL/Windows dual-path semantics

Description

When running inside WSL, file paths exist in two namespaces:

• Linux: /mnt/c/Users/Charles Lee/...
• Windows: C:\Users\Charles Lee\...

Gemini 3.1 Pro repeatedly confused these namespaces during agentic tasks:

• Used cat "C:\path\to\file" in a WSL shell (fails with "No such file or directory")
• Suggested find /mnt/c/... recursively, triggering WSL 9P kernel deadlocks (documented Microsoft known issue)
• Wrote mcp.json paths using C:\ Windows-style absolute paths inside JSON configs meant to be read by Linux-side processes

Claude Sonnet 4.6 in the same environment consistently used /mnt/c/ paths in shell contexts and C:\ paths in PowerShell/Windows contexts without confusion.

---

Bug #4: ginit alias/script silently broken — no error surfaced

Description

A custom ginit alias was previously set up to configure project settings. After a Gemini-assisted session, the alias was silently removed from ~/.bashrc (presumably overwritten during a session in which the model edited dotfiles). The CLI showed Command 'ginit' not found with no history of what caused the removal.

---

Bug #5: PreToolUse hook name not recognized — documented as preTool

Description

Gemini CLI documentation (or auto-generated settings.json) used preTool as the hook event name. The actual valid key is PreToolUse. This mismatch caused all destructive-command prevention hooks to silently fail, as the wrong event name was never triggered.

---

Performance Comparison: Gemini 3.1 Pro vs Claude Sonnet 4.6 in WSL

This is not a complaint about Gemini as a model overall, but a clear signal that Gemini 3.1 Pro's system prompts or fine-tuning lack specific handling for the WSL dual-path environment — an environment that is extremely common for developers on Windows.

---

Requested Actions

1. Fix the MCP config path resolution to handle WSL's dual-path namespace (Linux home + Windows mount).
2. Add a guard against git init in root or near-root paths (C:, /, /mnt/c/).
3. Fix PreToolUse hook documentation/generation — ensure the correct event name is used.
4. Improve /mcp diagnostics to show which config file paths were searched and what was found/missing.
5. Consider a WSL-specific system prompt addendum for Gemini models that clarifies path semantics.

---

Additional Context

• This was reproduced across multiple sessions over several days.
• The Gemini CLI version was v0.39.1 throughout.
• GitHub repository used for sync testing: https://github.com/jyongchul/multi-server-sync