Claude Code v2.1.219 · 24 Jul 2026
A bad CLAUDE_CODE_GIT_BASH_PATH on Windows now warns and auto-detects instead of quitting.
Use it now Tier: how much it should matter to you
4 Useful: my rating, 1 to 5
0 Signal: worth watching, 1 to 5
Windows Area: what it touches
Bug Fixes Kind: in v2.1.219, 24 Jul 26
What probably matters to you Section of the release
What
On Windows, pointing the variable at a path that does not exist used to print an error and call process.exit(1). It now warns and carries on.
Details
Falls back to normal auto-detection instead of exiting The path is additionally rejected unless its basename is bash.exe, sh.exe, bash or sh Windows git-bash lookup only Evidence
falling back to auto-detection
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
How sure we are
One source agrees One thing we can check says the same as this entry.
Anthropic's release notes agree Fixed CLAUDE_CODE_GIT_BASH_PATH on Windows exiting or being used as bash when the path isn't a bash/sh binary; it's now ignored with a…
See this entry in the whole of v2.1.219 →
24 Jul 2026 · 166 entries, this one is #17.
Use it now18 You'll notice71 Nothing to try yet31 Under the hood46
Open the release →
Names in this entry
env CLAUDE_CODE_GIT_BASH_PATH Windows only: path to the Git Bash executable (bash.exe). Use when Git Bash is installed but not in your PATH. If the path doesn't exist or the file isn't named bash.exe, sh.exe, bash, or sh, Claude Code ignores the variable and auto-detects Git Bash as if it were unset, logging a warning visible with --debug. Before v2.1.219, Claude Code exited at startup when the path didn't exist, and used any existing file as the shell without checking that it was bash or sh. See Windows setup
Anthropic's note
Upstream's own release notes for v2.1.219 name something this entry names, so the two are probably about the same change. Probably: the pairing is made on a shared name rather than on the words around it.
Fixed CLAUDE_CODE_GIT_BASH_PATH on Windows exiting or being used as bash when the path isn't a bash/sh binary; it's now ignored with a warning
Is this right?
0
0
Feedback
What's wrong with this entry?
Hard to understand Too vague Looks wrong Not relevant to me Too long Missing the detail I wanted Duplicate of another card
Clear Learned something new I can act on this Good catch
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
← Previous · 16 of 166
claude mcp list shows why a server failed
Use it now MCP
In v2.1.219 What probably matters to you release-page order
Next → · 18 of 166
MCP policy allow/deny entries now expand ${VAR} environment references, and unsafe URL…
Use it now MCP