claude-code - 💡(How to fix) Fix [BUG] Extension stuck on "loading models" in WSL when ~/.bashrc contains blocking commands (bash -lic PATH probe hangs indefinitely) [1 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

The Claude Code VS Code extension hangs indefinitely on "loading models" in WSL2 environments when the user's ~/.bashrc contains any blocking command (typically sudo without NOPASSWD, but any command waiting on /dev/tty triggers it). No error is shown to the user — the webview loads, but /model never responds, prompts get no reply, and "Open new tab" does nothing.

The extension spawns bash -lic at activation to probe the user's PATH. Confirmed by grepping extension.js from the installed extension bundle — the literal string printenv PATH is present. This probe inherits the user's ~/.bashrc, and if any line in .bashrc blocks waiting for input, the probe never returns and the claude native binary is never spawned.

This does not happen on VS Code native Windows (no .bashrc to source).

Environment

• OS: Windows 11 Insider Canary build 26200
• WSL: WSL2, Ubuntu 24.04.3 LTS (noble)
• Kernel: Linux 6.6.114.1-microsoft-standard-WSL2 x86_64
• VS Code: 1.115.0 (commit 41dd792b5e652393e7787322889ed5fdc58bd75b, x64)
• Node (in vscode-server): v20.20.1
• Claude Code extension: 2.1.112
• Remote-WSL extension: 0.99.0

Steps to Reproduce

1. Use VS Code with Remote-WSL on a WSL2 Ubuntu install.
2. Add a blocking command to ~/.bashrc, e.g.:

   sudo service mysql start > /dev/null 2>&1

   (any sudo without NOPASSWD, or read, or ssh with passphrase prompt, reproduces it)
3. Open VS Code, connect to WSL, open the Claude Code panel.
4. Observe: webview loads, "loading models" spinner runs forever. /model doesn't respond. Sending a prompt produces nothing.
5. Extension Host log (Anthropic.claude-code) stops at launch_claude with no further lines.

Expected Behavior

Either:

• The PATH probe times out after a reasonable window (5-10 s) and falls back to the parent process PATH, OR
• A clear error appears in the webview indicating the environment probe timed out and suggesting the user check shell rc files.

Root Cause Analysis

-l (login) + -i (interactive) sources ~/.bashrc. When .bashrc contains sudo <cmd> without NOPASSWD, sudo opens /dev/tty to prompt for the password. Under Node-spawned bash there is no TTY, so sudo blocks forever. The extension never receives the probe output and never spawns the claude native binary.

Diagnosis (how to confirm)

In a real WSL terminal (not the broken VS Code session):

ps -eo pid,etime,cmd | grep extensionHost | grep -v grep
pstree -p <PID>

Telltale signature: no claude(...) child under the extensionHost, and instead a bash->sudo chain hanging off it.

Workaround (user-side)

Wrap blocking .bashrc lines in a TTY check:

# Before:
sudo service mysql start > /dev/null 2>&1

# After:
[ -t 0 ] && [ -t 1 ] && sudo service mysql start > /dev/null 2>&1

Then kill the stuck bash/sudo processes and Developer: Reload Window. Extension works immediately.

Suggested Fixes (extension-side)

1. Timeout on the PATH probe — abort bash -lic after N seconds and fall back to the parent process PATH.
2. Surface feedback in the webview when the probe times out.
3. Log the probe command and duration in the extension log.
4. Document in troubleshooting that WSL users with .bashrc blocking commands may hit this.

Additional Notes

This was initially misdiagnosed as a version compatibility issue (pin to 2.1.77 appeared to "work"). It was not — 2.1.77 simply predated the addition of the blocking command to .bashrc. The bug reproduces on all versions that contain the printenv PATH probe.