## Describe the bug After updating to v2.1.45, all Bash tool invocations fail with `Exit code 1` and produce zero output. This includes trivial commands like `echo hello` and `pwd`. This worked correctly before today's update. ## To reproduce 1. Windows 11 with both Git Bash and WSL installed 2. PATH contains multiple bash executables (Git Bash, WSL bash, WindowsApps bash) 3. Update Claude Code to v2.1.45 4. Run any Bash tool command — all return `Exit code 1` with no output ## Observed beha

[BUG] v2.1.45 Windows: Bash tool fails silently (exit code 1) when WSL bash is on PATH alongside Git Bash

Status Fixed / completed

Reported on v2.1.45

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 9 comments · opened Feb 18, 2026 · closed Feb 19, 2026

Describe the bug

After updating to v2.1.45, all Bash tool invocations fail with Exit code 1 and produce zero output. This includes trivial commands like echo hello and pwd. This worked correctly before today's update.

To reproduce

Windows 11 with both Git Bash and WSL installed
PATH contains multiple bash executables (Git Bash, WSL bash, WindowsApps bash)
Update Claude Code to v2.1.45
Run any Bash tool command — all return Exit code 1 with no output

Observed behavior

| Command | Result |
|---------|--------|
| echo hello | Exit code 1, no output |
| pwd | Exit code 1, no output |
| ls -la | Exit code 2, no output |
| git --version | Works (native .exe) |
| claude --version | Works (native .exe) |
| where bash | Works — returns 3 paths |

Native Windows executables work. Bash builtins and Unix-style commands fail. This suggests the shell layer is not spawning bash correctly and falling back to a limited execution mode.

Bash executables on PATH (`where bash`)

C:\Program Files\Git\usr\bin\bash.exe    (Git Bash)
C:\Windows\System32\bash.exe             (WSL launcher)
C:\Users\user\AppData\Local\Microsoft\WindowsApps\bash.exe  (WSL alias)

bash --version from PowerShell returns: GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu) — confirming WSL bash is being resolved instead of Git Bash.

Expected behavior

Bash tool should use Git Bash (C:\Program Files\Git\bin\bash.exe) and execute commands normally, as it did in previous versions.

Environment

Claude Code version: 2.1.45
OS: Windows 11 Pro 10.0.26100
Shell: bash (WSL resolving over Git Bash)
Git Bash: installed at C:\Program Files\Git\
WSL: installed (Ubuntu)

Likely cause

Shell resolution in v2.1.45 appears to pick up C:\Windows\System32\bash.exe (WSL launcher) which fails silently when invoked programmatically, instead of using Git Bash. Previous versions handled this correctly.

Workaround

Setting CLAUDE_CODE_GIT_BASH_PATH or preferredShell config to the Git Bash path should resolve it.

Related issues

#19653 — WSL binary executes Bash commands through Windows
#12115 — Bash commands fail with exit code 1 and no output
#15471 — Windows Shell Compatibility Issue
#25593 — Windows requires git-bash after install

View original on GitHub ↗

9 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

designbyian · 6 months ago

I can confirm this in Claude Code CLI on windows.

I spent a few hours trying to track the cause down before I realized that it was a silent CC version update that vibebroke it. Highlights: there's nothing useful in CC debug logs or shell snapshots, no combination of PATH entries, dotfile updates, environment variables or registry key edits solves it. At least not that I found.

For anyone that happens across this, don't waste time trying to figure it out, downgrading to 2.1.44 is the best option for now:

curl -fsSL https://claude.ai/install.cmd -o ./install.cmd && ./install.cmd 2.1.44 && del install.cmd

frostbtn · 6 months ago

There it is. The difference is in the spawn call itself:

Broken 2.1.45:

HP$.spawn(G, Q, {
    env: {...},
    cwd: F,
    stdio: ["pipe", w, w],  // stdout/stderr -> file fd
    detached: _.detached,
    windowsHide: !0
})

Working 2.1.44:

AF$.spawn(G, Q, {
    env: {...},
    cwd: F,
    // no stdio -> defaults to "pipe" for all streams
    detached: _.detached,
    windowsHide: !0
})

The working version omits stdio, so Node.js defaults to "pipe" -> stdout/stderr come back as readable streams (J.stdout, J.stderr) that oP$ reads directly.

The broken version redirects stdout/stderr to w (a Windows file descriptor opened with openSync). On Windows, when Git Bash (MSYS2) inherits a Windows HANDLE as its stdout, the MSYS2 POSIX layer doesn't recognize it as fd 1 -> it keeps the console as stdout. So the shell writes to the terminal, the file gets nothing, and Claude reads an empty file.

! ls > file works in the shell because bash opens a fresh fd for that redirect itself, bypassing the inherited (broken) fd 1 entirely.

The broken version added file-based capture (likely for transcript/logging purposes), but didn't account for Windows handle inheritance being incompatible with MSYS2.

---

Unfortunately, it is not as patchable as I'm doing with markdown styling misalignment in #17892, so we need to wait. The good news, they've fixed --verbose in this 2.1.45 that was broken since late 1.2.30s. Fix one, break another--we're nearing the "told ya" moment with autonomous coding agents being not there yet, and the codebase eventually start deteriorating without proper oversight.

benmcneil · 6 months ago

Thanks, had the same issue today and downgrading to 2.1.44 worked.

jmperez0 · 6 months ago

I encountered the same issue. Rolling back one version resolved it for me as well. By the way, Claude was not effective in diagnosing the problem.

jgprocha · 6 months ago

I wasted a huge amount of time and quota on this issue before finally realizing where the issue was, trying everything possible (with Claude itself being very ineffective at helping) before finally downgrading. And that was after a huge amount of frustration with Claude basically becoming completely useless. Worth noting for others that you need to set an environment variable, DISABLE_AUTOUPDATER=1 after downgrading or it'll just get upgraded again. At the very least I don't understand why they don't roll out a new version that's just rolling back this update, since it effectively bricks Claude for windows.

dmastag · 6 months ago

I tried on the latest 2.1.47 Release, and it works again
For both CLI and VS Code Extension

AshExplained · 6 months ago

2.1.47 Release fixed this. closing report