Skip to content

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

Closed as not planned
Bug
Closed as not planned
WSL2: Cascade of critical bugs — OAuth session loss, hook schema breaking change (v0.39.1), EPIPE crashes, and untrusted workspace prompt blocking --yolo mode#26111
Bug
Labels
Stalearea/platformIssues related to Build infra, Release mgmt, Testing, Eval infra, Capacity, Quota mgmtkind/bugpriority/p1Important and should be addressed in the near term.status/manual-triage

Description

@jyongchul
jyongchul
opened on Apr 28, 2026

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.

Activity

  1. gemini-cli
    added
    status/need-triageIssues that need to be triaged by the triage automation.
    on Apr 28, 2026

  2. jyongchul commented on Apr 28, 2026

    @jyongchul
    jyongchul
    on Apr 28, 2026
    Author

    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.

  3. jyongchul commented on Apr 28, 2026

    @jyongchul
    jyongchul
    on Apr 28, 2026
    Author

    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)

  4. jyongchul commented on Apr 29, 2026

    @jyongchul
    jyongchul
    on Apr 29, 2026
    Author

    ⚠️ 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.

  5. gemini-cli
    added
    area/platformIssues related to Build infra, Release mgmt, Testing, Eval infra, Capacity, Quota mgmt
    kind/bug
    status/bot-triaged
    status/manual-triage
    on May 7, 2026

  6. gemini-cli commented on May 7, 2026

    @gemini-cli
    gemini-clibot
    on May 7, 2026 – with gemini-cli
    Contributor

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

  7. gemini-cli
    removed
    status/need-triageIssues that need to be triaged by the triage automation.
    on May 8, 2026
  8. gemini-cli
    added the
    Bug
    issue type on May 8, 2026
  9. github-project-automation
    added this to Gemini CLI Public Roadmapon May 8, 2026
  10. gemini-cli
    added
    area/securityIssues related to security
    and removed
    status/bot-triaged
    on May 12, 2026

  11. gemini-cli commented on May 12, 2026

    @gemini-cli
    gemini-clibot
    on May 12, 2026 – with gemini-cli
    Contributor

    P0 requires manual triage.

  12. gemini-cli
    added
    priority/p1Important and should be addressed in the near term.
    status/bot-triaged
    status/need-information
    on May 13, 2026

  13. gemini-cli commented on May 13, 2026

    @gemini-cli
    gemini-clibot
    on May 13, 2026 – with gemini-cli
    Contributor

    Please provide the CLI version.

  14. gemini-cli
    removed
    status/need-information
    on May 13, 2026
  15. cocosheng-g
    removed
    status/bot-triaged
    on May 13, 2026
  16. gemini-cli
    added
    status/bot-triaged
    and removed
    area/securityIssues related to security
    status/bot-triaged
    on May 14, 2026
  17. gemini-cli
    added
    Stale
    on Jul 14, 2026

  18. gemini-cli commented on Jul 14, 2026

    @gemini-cli
    gemini-clibot
    on Jul 14, 2026 – with gemini-cli
    Contributor

    This bug report has been automatically marked as stale due to 60 days of inactivity. Many issues are resolved in newer releases. Please verify if the issue persists in the latest Gemini CLI version. If it does, please leave a comment to keep this open. It will be closed in 14 days if no further activity occurs. Thank you!

  19. gemini-cli commented on Jul 29, 2026

    @gemini-cli
    gemini-clibot
    on Jul 29, 2026 – with gemini-cli
    Contributor

    This item has been closed due to 14 additional days of inactivity after being marked as stale. If you believe this is still relevant, feel free to comment or reopen. Thank you!

  20. gemini-cli
    closed this as not plannedon Jul 29, 2026
  21. github-project-automation
    moved this to Closed in Gemini CLI Public Roadmapon Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Stalearea/platformIssues related to Build infra, Release mgmt, Testing, Eval infra, Capacity, Quota mgmtkind/bugpriority/p1Important and should be addressed in the near term.status/manual-triage

    Type

    Bug

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions