WSL2: Cascade of critical bugs — OAuth session loss, hook schema breaking change (v0.39.1), EPIPE crashes, and untrusted workspace prompt blocking --yolo mode

[jyongchul]

Environment

• OS: Windows 11 with WSL2 Ubuntu 24.04
• Node.js: v22.17.0
• Gemini CLI version: v0.39.1 (npm global install)
• Auth mode: oauth-personal (Google One AI Ultra subscription)
• Shell: bash (WSL2)

---

Summary

After weeks of production use of gemini-cli in WSL2 for autonomous agentic workflows (--yolo mode), we encountered a cascading series of bugs that collectively make the CLI unreliable for WSL2 development. Each fix reveals the next. This documents 5 confirmed bugs.

---

Bug 1: OAuth Session Silently Invalidates

Symptom: Failed to sign in: Cloud Code Private API not enabled drops into interactive auth menu, blocking automation.

Root cause:

• ~/.gemini/google_accounts.json shows "active": null after silent token drop
• ~/.gemini/projects.json accumulated corrupt entry "/mnt/c": "c" from a session launched from Windows-mounted path — binding workspace to wrong GCP project

Fix: Background token refresh + prune stale projects.json + gemini auth reset command

---

Bug 2: Hook Schema Silent Breaking Change in v0.39.1

Symptom: Error in: hooks.AfterAgent[0] Expected object, received string on every startup.

Root cause (confirmed by reading bundle source chunk-WFCK2Z32.js):

Old valid format (now silently discarded):

"hooks": { "SessionStart": ["echo 'hello'"] }

New required Zod schema:

"hooks": { "SessionStart": [{ "hooks": [{ "type": "command", "command": "echo 'hello'" }] }] }

No auto-migration, no docs update, error message doesn't show correct format. Hooks are silently discarded via debugLogger.warn (invisible to user).

---

Bug 3: EPIPE Crash on AfterAgent Hook

Symptom: Error: write EPIPE at writeToStdout — CLI crashes after every agent turn.

Even nohup ... >/dev/null 2>&1 & doesn't prevent it. Hook subprocess inherits parent stdout during teardown.

Fix: Execute AfterAgent hooks in fully detached subprocess (new process group).

---

Bug 4: Untrusted Workspace Warning Blocks --yolo Mode

Interactive trust prompt appears even with --yolo flag. security.folderTrust.enabled: false does not suppress it. Fundamental regression for YOLO-mode users.

---

Bug 5: /mnt/c/ Path Corrupts projects.json

Launching CLI from Windows-mounted path creates stale "/mnt/c": "c" in projects.json that causes Cloud Code API errors in future sessions.

---

Comparative Observation

Running Claude Sonnet 4.6 in the identical WSL2 environment with identical hooks/configs produces zero warnings, zero EPIPE crashes, zero session loss, and consistent YOLO-mode automation. This isolates the issues to Gemini CLI's WSL2 integration layer specifically.

[jyongchul]

Follow-up: Continued WSL2 Instability + Model-Level Reliability Comparison (Gemini 2.5 Pro vs. Claude Sonnet 4.6)

I am following up on this issue to report that the instability described above is not isolated to the 5 bugs originally filed. After several additional weeks of production use, I have documented a persistent, broader pattern of WSL2 environment failures that compounds with every Gemini CLI update. I am also adding a direct model-reliability comparison that is relevant to evaluating the root cause.

---

Continued Cascading Failures in WSL2 (Post-v0.39.1)

The following additional failure categories have been observed in my environment (Windows 11 + WSL2 Ubuntu 24.04, identical setup as the original report):

A. Process Deadlocks / Terminal Bouncing

After an agent turn that involves heavy tool calls (file I/O, git operations), the CLI process enters a deadlock state where it neither completes nor errors. The terminal appears frozen and the only recovery is kill -9. This occurs roughly 1-in-4 sessions. The WSL process does not terminate cleanly — it leaves zombie node processes attached to the WSL bridge. This was documented across multiple debugging sessions and is reproducible.

B. --yolo Mode Interrupted by WSL Service Restarts

The WSL2 service occasionally restarts its networking stack mid-session (particularly after the host Windows machine goes into sleep/resume cycles). When this happens, the Gemini CLI does not detect the broken pipe gracefully — instead it hangs indefinitely, blocking all autonomous task execution. There is no timeout, no retry, and no log entry indicating the cause. Recovery requires full WSL restart.

C. MCP Server Failures Cascade into CLI Config Corruption

When an MCP server process (defined in ~/.gemini/settings.json) fails to start, the CLI silently continues but leaves the config in a half-initialized state. On next startup, this causes malformed reads of settings.json and requires manual deletion and re-creation of the file. This has happened on 3 separate occasions across different projects.

D. OAuth Token Loss After WSL Snapshot/Restore

Any operation that suspends and restores the WSL instance (Windows fast startup, hibernation, etc.) reliably invalidates the OAuth session — the same "active": null behavior described in Bug 1. The token refresh mechanism does not run proactively; it only fails loudly at the next user prompt. In --yolo mode, this silently aborts the autonomous task with no notification.

---

Model-Level Reliability Comparison: Gemini 2.5 Pro vs. Claude Sonnet 4.6

To isolate whether these issues are CLI-level bugs versus model-level behavior, I ran identical autonomous agentic workflows in the same WSL2 environment using two different CLI tools:

Metric	Gemini CLI (Gemini 2.5 Pro)	Claude Code CLI (Claude Sonnet 4.6)
Session crashes / deadlocks	Frequent (est. 25% of sessions)	Zero observed across equivalent sessions
EPIPE crashes	Occurs after agent turns (Bug 3 above)	Not observed
Auth session drops	After WSL suspend/resume (Bug 1 above)	Not observed
--yolo / autonomous mode blocking	Yes — interactive prompts break automation	Not observed
MCP config corruption on server failure	Yes — requires manual file recovery	Graceful degradation, no corruption
Recovery from WSL network interruption	Hangs indefinitely, requires kill	Detects broken pipe, exits cleanly

Conclusion: Claude Code CLI, operating in the identical WSL2 environment with identical shell configuration and hooks, does not exhibit any of these issues. This provides strong evidence that the failures are specific to Gemini CLI's WSL2 integration layer — not the WSL2 environment itself.

This comparison is not intended as a product critique, but as a diagnostic data point. If the reference CLI handles these edge cases correctly, the expected behavior is achievable, and the gap represents fixable bugs.

---

Request

Given the severity of these issues for WSL2 users running autonomous/agentic workflows, I would like to request:

1. An official statement on WSL2 support status (is it a first-class target environment?)
2. A fix for the --yolo mode blocking on any interactive prompt (regression from Bug 4)
3. Graceful EPIPE handling so that AfterAgent hook crashes do not terminate the session
4. Proactive OAuth token validation on session start (not just on first API call)

Happy to provide additional logs, reproducible shell scripts, or detailed environment dumps on request.

[jyongchul]

Follow-up #2: Live Reproduction — Fork Exhaustion Deadlock Requiring Full Windows-Level Kill

Posting this immediately after a live reproduction of the deadlock pattern, which escalated to full WSL unresponsiveness.

---

What Happened (Reproduced: 2026-04-28, ~23:00 KST)

After a standard gemini --yolo session in WSL2 Ubuntu 24.04, the following error appeared on next launch attempt:

-bash: fork: retry: Resource temporarily unavailable
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: retry: Resource temporarily unavailable
/home/charles_lee/.npm-global/bin/gemini: fork: retry: Resource temporarily unavailable

Diagnosis via ps aux: The Windows host was found to have accumulated 5 wsl.exe ghost processes and 14 wslhost.exe ghost processes — all orphaned from previous Gemini CLI sessions that deadlocked and never cleaned up their subprocesses.

Id    Name       WorkingSet
3784  vmcompute  13414400
31492 vmmem      (large)
20900 wsl        6209536
26440 wsl        7204864
27744 wsl        10457088
28008 wsl        7512064
32064 wsl        10178560
11260 wslhost    (x14 instances)

Additionally, systemd-journald was found in uninterruptible D state inside WSL, blocking both wsl --shutdown and wsl --terminate Ubuntu.

Recovery required:

1. Stop-Process -Name "wsl" -Force (Windows PowerShell, killed all 5 ghost wsl.exe)
2. Stop-Process -Name "wslhost" -Force (killed all 14 ghost wslhost.exe)
3. Even after that, wsl --shutdown hung indefinitely because vmcompute.exe (the Hyper-V host) itself was stuck
4. Full Windows-level Restart-Service vmcompute -Force required

Total downtime from fork: retry error to usable WSL: ~20+ minutes, requiring elevated PowerShell intervention.

---

Root Cause Analysis

Gemini CLI's agent turns spawn subprocesses (MCP servers, AfterAgent hooks, shell tools) that are not properly reaped when the CLI deadlocks or is killed. Since --yolo mode keeps the CLI running as a long-lived process, each crashed/killed session leaves behind:

• Orphaned node subprocess trees
• Zombie entries consuming PID slots in the WSL kernel PID table
• Ghost WSL bridge sessions (wslhost.exe) on the Windows side that are never cleaned up

Over multiple sessions, these accumulate until the fork table is exhausted.

Claude Code CLI in the identical environment: Zero orphaned processes observed after equivalent sessions. Clean exit reaps all child processes correctly.

---

Proposed Fix

1. Gemini CLI should install a SIGTERM/SIGINT handler that explicitly kills all spawned child process groups before exit
2. AfterAgent hooks should be run in a detached process group with setsid so they don't inherit the CLI's process group
3. The CLI should call process.exitCode cleanup logic even on unhandled promise rejections

This is fixable at the Node.js process management level and does not require WSL changes.

---

Comparative Note

This is a third consecutive incident where Claude Code CLI handled the same workload cleanly while Gemini CLI left the system in an unrecoverable state. For teams running autonomous/agentic --yolo workflows, this level of instability makes Gemini CLI unreliable for production use on WSL2.

Related: #26111 (original cascade report), #26114 (paste input bug)

[jyongchul]

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

Correcting factual errors from earlier reports in this thread and in #26114, #26117:

• Model reported as: "Gemini 2.5 Pro"

• Actual model: gemini-3.1-pro-preview (confirmed from CLI footer)

• OS reported as: "Windows 11"

• Actual OS: Windows 10 (host)

All reliability comparisons, incident timelines, and metrics in the previous reports should be read with these corrections applied.

[gemini-cli]

Multiple severe reliability issues reported on WSL2. Potential P0 cluster, applying status/manual-triage.