[BUG] WSL2: Repeated powershell.exe calls for USERPROFILE cause ~60s startup delay

Running into this too. Wanted to add some data that might help.

On my setup (Claude 2.0.76, WSL2 2.6.3.0, Win11), I'm seeing the same powershell.exe calls but with different timing - about 700-900ms each instead of 10s. The interesting thing is there are way more of them than I expected: 21 calls in the first ~37 seconds, firing roughly every 1.7 seconds.

From my debug log:

  17:31:57.831Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (871ms): powershell.exe -Command '$env:USERPROFILE'
  17:32:03.113Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (789ms): powershell.exe -Command '$env:USERPROFILE'
  17:32:03.888Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (764ms): powershell.exe -Command '$env:USERPROFILE'
  ...
  17:32:33.740Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (696ms): powershell.exe -Command '$env:USERPROFILE'

The calls stop after that initial burst, which explains why the sluggishness goes away after ~30-40 seconds. During that window though, there's noticeable typing lag in the input - feels like the sync calls are blocking the UI thread.

Guessing the per-call latency difference (700ms vs 10s) is system-dependent - maybe AV, disk speed, or WSL config. But the redundant calling pattern seems consistent.

Adding another data point from Claude Code 2.0.76 on WSL2:

Environment:

• Claude Code: 2.0.76
• WSL2 on Windows (Ubuntu)
• Shell: bash

Observations:

• 20 PowerShell calls in a single session
• Each call takes ~1.1-1.15 seconds
• Total blocking time: ~22 seconds of startup latency
• Typing is blocked during these calls (can't input text until they complete)

Important finding: I have CLAUDE_CODE_SKIP_WINDOWS_PROFILE=1 set and exported in my .bashrc, confirmed active in my environment, but the deprecated code path ignores this flag entirely.

$ echo $CLAUDE_CODE_SKIP_WINDOWS_PROFILE
1

Debug log excerpt:

2026-01-05T11:09:26.843Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (1139.6ms): powershell.exe -Command '$env:USERPROFILE'
2026-01-05T11:09:28.613Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (1145.4ms): powershell.exe -Command '$env:USERPROFILE'
2026-01-05T11:09:29.755Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (1131.1ms): powershell.exe -Command '$env:USERPROFILE'
2026-01-05T11:09:30.921Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (1148.4ms): powershell.exe -Command '$env:USERPROFILE'
2026-01-05T11:09:33.055Z [DEBUG] [SLOW OPERATION DETECTED] execSyncWithDefaults_DEPRECATED (1117.4ms): powershell.exe -Command '$env:USERPROFILE'
... (15 more calls)

Suggested fix: The execSyncWithDefaults_DEPRECATED function should check for CLAUDE_CODE_SKIP_WINDOWS_PROFILE before spawning PowerShell, or cache the result after the first call.

Thanks to @tariq2sa, @bryanm1529, and @TimonKai for identifying this issue!

I encountered a similar problem.

Confirmed Workaround

I can confirm that the following environment variables completely resolve the startup delay in WSL2:

# Add to ~/.bashrc
export CLAUDE_CODE_SKIP_WINDOWS_PROFILE=1
export USERPROFILE="/mnt/c/Users/<your-username>"

My Environment

• OS: Windows 11 + WSL2 (Ubuntu)
• Terminals tested: Windows Terminal, VS Code integrated terminal
• Claude Code version: 2.1.7

Before vs After

| Metric | Before | After |
|--------|--------|-------|
| Loading skills → Loaded plugins | ~4100ms | ~7ms |
| setup() completion | ~4400ms | ~50ms |
| /status or /doctor or other command delay | ~2700ms | ~20ms |

Key Observation

Before applying the fix, Windows Terminal was significantly slower than VS Code Terminal. After setting these environment variables, both terminals are equally fast.

This suggests that VS Code's CLAUDE_CODE_ENTRYPOINT=claude-vscode environment may have been partially bypassing this issue, but the root cause (repeated powershell.exe calls) was still present.

Hope this helps other WSL2 users!

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.