google-gemini
Extreme Startup Latency on WSL2 (>4 minutes TTI)
What happened?
I am experiencing severe startup latency when running the gemini CLI on Linux/WSL2 (Ubuntu 24.04.3). The tool consistently takes between 4 and 4.5 minutes** (approx. 240s–270s) to become interactive after the command is issued.
I measured the Time-to-Interactive (TTI) using an automated expect script that logs the time from process launch to the appearance of the "Tips for getting started" banner. The results are consistently reproducible:
[2025-12-16] [18:17:33 -> 18:22:01] [Linux/WSL2] Startup: 267916ms (267.916s)
[2025-12-16] [19:13:47 -> 19:17:50] [Linux/WSL2] Startup: 243102ms (243.102s)
[2025-12-16] [19:32:02 -> 19:36:30] [Linux/WSL2] Startup: 268298ms (268.298s)
Even running the tool with the --help flag—which should presumably be instantaneous—takes nearly 2 minutes:
[2025-12-16] [19:08:44 -> 19:10:36] [Linux/WSL2] Startup: 111557ms (111.557s)
[2025-12-16] [19:19:11 -> 19:21:30] [Linux/WSL2] Startup: 138433ms (138.433s)
What did you expect to happen?
I expected the CLI to start and become interactive within a few seconds, as it does on other platforms.
Crucially, on the exact same physical machine, running gemini in native PowerShell 7+ (Windows 11) is virtually instantaneous. This snappy performance on Windows persists even with multiple MCP servers configured, ruling out hardware resources or general network issues as the cause.
Client information
- CLI Version: 0.20.2
- Git Commit: af894e468
- Session ID: 583feec4-75a8-40fd-96f5-1abd5cb18aba
- Operating System: Linux v24.12.0
- Sandbox Environment: no sandbox
- Model Version: pro
- Memory Usage: 284.6 MB
Login information
/
Anything else we need to know?
- Environment: Ubuntu 24.04.3 LTS on WSL2 (Windows 11).
- Isolation: The issue is specific to the Linux/WSL environment; native Windows performance is flawless.
- File System Independent: The latency persists regardless of whether the project is located in the native Linux file system (
/home/<user>) or the mounted Windows file system (/mnt/c/Users/<user>). - MCP Config: The presence or absence of configured MCP servers makes no measurable difference to the startup time on either platform.
- Measurement Method: Timings were captured using an automated
expectscript to measure the precise delta between process launch and the rendering of specific ANSI sequences in the help banner.
There's a StartupProfiler class in packages/core/src/telemetry/startupProfiler.ts that tracks startup phases.
It collects os_platform, os_release, and is_docker info but doesn't specifically detect WSL.
The detection for Docker uses fs.existsSync('/.dockerenv') - similar detection could be added for /proc/sys/fs/binfmt_misc/WSLInterop to identify WSL.
By the way, for the first time I started gemini in a second bash, and it started and was responsive immediately (with 6 MCP servers). I tried it a few times again, and it seems as long as I have one gemini instance already running, the next one starts right away without noticeable delay.