Describe the bug
When running Gemini CLI inside a WSL2 (Ubuntu) terminal while the working directory is located on a Windows mounted drive (e.g., /mnt/c/...), the CLI frequently triggers a severe system deadlock (often resulting in terminal freezes, forkpty(3) failed, core dumped, or Exit Code: 134).
This appears to be caused by the Windows-Linux file bridge (9P protocol) being overwhelmed by the CLI's aggressive I/O operations, such as wide directory scanning, file indexing, or spawning cross-OS processes (e.g., executing powershell.exe or chrome.exe on Windows directly from the WSL environment).
Steps to reproduce
- Open a WSL2 terminal (e.g., Ubuntu).
- Navigate to a large project directory located on the Windows host (e.g.,
cd /mnt/c/Users/Name/LargeProject).
- Run Gemini CLI and ask it to perform actions that involve heavy file system traversal or executing cross-OS shell commands (like
powershell.exe -Command ...).
- The terminal hangs indefinitely or crashes due to 9P protocol bottlenecks and memory exhaustion.
Expected behavior
The CLI should either:
- Detect if the current working directory is a cross-OS mount (like
/mnt/c/) under WSL and warn the user, or optimize its file scanning/polling to prevent overwhelming the 9P bridge.
- Provide a robust proxy or fallback mechanism for executing host OS commands without triggering deadlocks.
- Fail gracefully with a clear error message instead of causing the entire terminal session to freeze/hang.
Additional context
Currently, to work around this, we have to enforce a "Cross-OS I/O Bypass Protocol" where we rsync the code to a native Linux directory (~/.tmp_workspace), run the CLI operations there, and sync it back. Running Gemini CLI natively via Windows PowerShell avoids the issue entirely, but many users prefer WSL2 for development.
Describe the bug
When running Gemini CLI inside a WSL2 (Ubuntu) terminal while the working directory is located on a Windows mounted drive (e.g.,
/mnt/c/...), the CLI frequently triggers a severe system deadlock (often resulting in terminal freezes,forkpty(3) failed,core dumped, orExit Code: 134).This appears to be caused by the Windows-Linux file bridge (9P protocol) being overwhelmed by the CLI's aggressive I/O operations, such as wide directory scanning, file indexing, or spawning cross-OS processes (e.g., executing
powershell.exeorchrome.exeon Windows directly from the WSL environment).Steps to reproduce
cd /mnt/c/Users/Name/LargeProject).powershell.exe -Command ...).Expected behavior
The CLI should either:
/mnt/c/) under WSL and warn the user, or optimize its file scanning/polling to prevent overwhelming the 9P bridge.Additional context
Currently, to work around this, we have to enforce a "Cross-OS I/O Bypass Protocol" where we
rsyncthe code to a native Linux directory (~/.tmp_workspace), run the CLI operations there, and sync it back. Running Gemini CLI natively via Windows PowerShell avoids the issue entirely, but many users prefer WSL2 for development.