[BUG] Bash tool permanently broken with WSL2: unexpected EOF while looking for matching quote

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug Description

On Windows 11 with WSL2 installed, the Claude Code Bash tool becomes permanently broken in a session, failing with:

/usr/bin/bash: -c: line 80: unexpected EOF while looking for matching ''`

Every subsequent Bash tool call in that session fails with the same error, even for trivial commands like echo hello.

Environment

• OS: Windows 11 Pro (10.0.26200)
• WSL2: Ubuntu (default distro)
• Claude Code: VS Code terminal
• Project location: Windows filesystem (D:\...)

Key Observation: Inconsistent Shell Selection

Multiple Claude Code windows opened from the same VS Code terminal produce different results:

| Window | Shell Used | Bash Tool |
|--------|-----------|-----------|
| This window | /usr/bin/bash (WSL) | Broken |
| Other windows | Likely Git Bash | Working fine |

All windows were opened the same way (VS Code terminal on Windows). Claude Code's shell auto-detection appears non-deterministic — sometimes it picks WSL bash, sometimes Git Bash, with no user-configurable way to force a choice.

Reproduction

1. Open Claude Code in VS Code terminal on Windows 11 with WSL2 installed
2. If Claude Code selects /usr/bin/bash (WSL) as the shell, the Bash tool fails
3. Once broken, all Bash commands in that session fail permanently
4. Closing and reopening the session may or may not fix it (depends on which shell is auto-detected next time)

Root Cause Analysis

Layer 1: WSL .bashrc incompatibility (partially fixed)

WSL's default .bashrc contains an alias alert=... line with nested single quotes that fails under non-interactive bash -c parsing. This was fixed by removing the alias, but the Bash tool remained broken.

Layer 2: Shell selection is non-deterministic and non-configurable

Claude Code has no shellPath setting to let users specify which shell the Bash tool should use. The auto-detection logic is opaque and produces inconsistent results across sessions started the same way.

Layer 3: Bash tool state is not recoverable

Once the Bash tool fails to initialize, it stays broken for the entire session. There's no fallback mechanism (e.g., retry with Git Bash) or way to reset it.

Workaround

• Restart the session and hope it picks Git Bash instead of WSL bash
• Use ! prefix to run commands manually via the terminal
• Use Read/Write/Edit/Glob/Grep tools for file operations that don't need Bash

Suggested Fixes

1. Add shellPath configuration: Allow users to specify the shell path in settings.json (e.g., "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe")
2. Auto-fallback on initialization failure: If the selected shell fails to initialize, automatically try an alternative (e.g., Git Bash when WSL bash fails)
3. Make shell detection transparent: Log which shell was selected and why, so users can diagnose issues
4. Skip WSL bash when project is on Windows filesystem: If the working directory is on a Windows drive (C:\, D:\, etc.), prefer Git Bash over WSL bash

Impact

• Severity: High — makes the Bash tool completely unusable in affected sessions
• Frequency: Non-deterministic — depends on shell auto-detection result at session start
• Data loss risk: None, but blocks all git/script operations in the session

What Should Happen?

fix it

Error Messages/Logs

Steps to Reproduce

null

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.148 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_