Windows/Git Bash: Bash tool PATH becomes Windows/Unix hybrid after a plugin/MCP connects mid-session, breaking node/git/coreutils

Summary

On Windows with Git Bash (MSYS2), the Bash tool's PATH becomes a malformed Windows/Unix hybrid mid-session whenever a plugin or MCP server connects and the harness rebuilds the Bash environment. After that, node, git, and even MSYS coreutils (cat, which, dirname, head) fail with command not found for the rest of the session — every Bash tool call is affected. PowerShell is unaffected.

Environment

• OS: Windows 11 Pro
• Shell: Git Bash / MSYS2 (MSYSTEM=MINGW64, SHELL=/bin/bash.exe)
• Claude Code: Bash tool runs bash -c "<command>" (non-interactive, non-login — confirmed $- = hBc, shopt -o posix = off)

Symptom

$ node -v
bash: line 1: node: command not found
$ cat --version
bash: line 1: cat: command not found
$ git --version       # some Windows-PATH bins still resolve by luck
git version 2.53.0.windows.2

echo (a builtin) and absolute paths (/usr/bin/echo) still work, so the shell itself is fine — only PATH resolution is broken.

Root cause

The Bash tool's PATH is a hybrid of two incompatible formats:

C:\WINDOWS\system32;C:\WINDOWS;...;C:\Program Files\nodejs;C:\Program Files\Git\mingw64\bin:/c/Users/.../plugin_XXXX/bin:/c/Users/.../skills-plugin/.../bin
└──────────────── Windows format: ";"-separated, raw "C:\" drive letters ───────────────┘└──────── Unix format: ":"-separated ────────┘

Git Bash/MSYS splits PATH on : (colon). Because the system portion is in Windows format (semicolon-separated with C:\ drive letters), every C: drive-letter colon fragments those entries into non-directories, and the proper MSYS dirs (/usr/bin, /mingw64/bin, the nodejs dir) never appear as clean :-separated entries. Result: almost nothing resolves by name.

The Unix-format tail (:/c/Users/.../plugin_*/bin) is the tell — those are plugin/MCP bin dirs appended in correct MSYS format. The breakage begins exactly when a plugin/MCP connects mid-session: the harness rebuilds the Bash env and concatenates the Unix-format plugin paths onto the raw, un-MSYS-converted Windows PATH instead of converting the Windows portion first (;→:, C:\→/c/). At session start (before any plugin loads) the PATH is clean and Bash works normally — the corruption is introduced by the rebuild.

Impact

• Any Windows + Git Bash user loses the Bash tool entirely the moment a plugin/MCP connects mid-session (a very common event).
• Silent and confusing: node/git/coreutils all vanish with no indication why.

Suggested fix

When constructing the Bash tool's environment on Windows/Git Bash, MSYS-normalize the inherited Windows PATH before appending plugin/MCP bin dirs — e.g. run it through cygpath -up (or apply the standard ;→: + C:\→/c/ conversion) so the whole PATH is a single consistent :-separated MSYS list. Equivalently, append the plugin dirs in Windows format if the rest is Windows format. The two formats must not be mixed.

Workarounds (confirmed)

• Use PowerShell for shell work — it uses the native Windows ;-PATH and is unaffected.
• Prepend a clean PATH in each Bash command: export PATH="/usr/bin:/mingw64/bin:/c/Program Files/nodejs:$PATH"; <cmd>
• BASH_ENV does NOT work as a fix here: setting BASH_ENV (via settings.json env) to a ~/.bashrc that re-prepends a clean PATH propagates correctly (the var is visibly set), but this harness's bash -c invocation does not source BASH_ENV (posix mode is off, yet the file is never read — verified the guard never runs on a fresh shell, while manually . "$BASH_ENV" fixes everything). So users can't self-fix via BASH_ENV; the fix has to be in how the harness builds the PATH.