gemini-cli - 💡(How to fix) Fix [gemini-3.1-pro-preview][Win10/WSL2] Model over-escalates transient network timeout to critical deadlock — instructs unnecessary wsl --shutdown [1 participants]

⚠️ CORRECTION: Model Name & OS Were Incorrect in All Previous Reports

Correcting factual errors from earlier reports:

• Model reported as: "Gemini 2.5 Pro" → Actual: gemini-3.1-pro-preview
• OS reported as: "Windows 11" → Actual: Windows 10

[gemini-3.1-pro-preview][Win10/WSL2] Model over-escalates WSL network timeout to "critical system deadlock" — instructs unnecessary wsl --shutdown

Environment: Windows 10 + WSL2 Ubuntu 24.04, gemini-3.1-pro-preview, Gemini CLI v0.40.0

What Happened

During a --yolo session in ~/projects/WM, WSL intermittently experienced network connectivity issues (TLS handshake timeouts to GitHub, git operations hanging). This is a known transient WSL network issue — ping to 8.8.8.8 was 100% successful throughout.

The model (gemini-3.1-pro-preview) also attempted to access:

1. /mnt/g — a drive letter that is not mounted in this WSL instance
2. powershell.exe — which returned Exec format error (intermittent WSL interop issue)

The model then declared a "치명적 데드락 (Critical Deadlock)" and instructed the user to immediately perform wsl --shutdown from an elevated PowerShell.

CLI Output at Time of Escalation

✦ 대표님, 현재 WSL(Linux) 터미널과 Windows Host 간의 I/O 브릿지가 붕괴된 치명적 데드락 상태가 감지되었습니다.

시스템 자율 검증 결과, Windows의 powershell.exe 및 cmd.exe 실행 시 Exec format error가 발생하며,
/mnt/g 경로 역시 마운트가 해제되어 G 드라이브에 접근할 수 없는 100% 연결 거부 상태입니다.

🚨 Windows PowerShell (관리자 권한)에서 wsl --shutdown 명령어로 커널을 강제 초기화(물리적 리부팅)하여
I/O 병목을 해소해 주십시오.

Actual System State

context:   5% used    ← session fully alive
quota:     4% used    ← no throttling
ping 8.8.8.8:  0% packet loss, 26ms  ← internet working
WSL status:    Running normally

The Real Problem

The model escalated a combination of:

• Missing drive mount (/mnt/g doesn't exist on this machine)
• Transient powershell.exe interop error (intermittent, self-resolving)
• Temporary GitHub TLS timeout (git operations recovered on their own within minutes)

...into an instruction to perform a destructive full WSL restart, which would have killed the active session and all background processes unnecessarily.

The network did recover on its own. The user did NOT need to run wsl --shutdown.

Expected Behavior

When encountering these conditions, the model should:

1. Missing mount (/mnt/g): Skip gracefully, do not treat as system failure
2. powershell.exe Exec format error: Fall back to Linux-only tools, retry once
3. Transient network timeout: Wait and retry (with backoff), inform user of temporary connectivity issue
4. If escalation is truly needed: Distinguish between "network is temporarily slow" vs "WSL is deadlocked" — these require very different responses

Under no circumstances should a missing drive letter or a 30-second network timeout trigger a recommendation to restart the WSL kernel.

Why This Matters

A user who trusts the model's diagnosis and runs wsl --shutdown will:

• Lose their active CLI session and all context
• Kill any background processes (cron jobs, MCP servers, etc.)
• Spend 2-3 minutes waiting for WSL to restart

All for a network blip that would have resolved itself.

This is a model judgment/escalation issue, not just a CLI bug. The model needs better heuristics for distinguishing transient errors from actual system failures in WSL2 environments.

Related Issues

• #26111 (WSL2 reliability cascade)
• #26117 (comprehensive 7-incident report)