Windows/Git Bash: session's Bash tool dies permanently (unalias: unsetenv, then "completed with no output") and does not recover on resume

Summary

On Windows + Git Bash, a long-lived session's Bash tool can enter a state where every command fails and never recovers, even after restarting the CLI on that session. The failure is bound to the session/process, not the machine or the CLI version: sibling sessions open at the same time work fine, and a brand-new session on the exact same CLI build has a fully working Bash. Resuming the broken session (--continue/--resume) re-attaches to the dead shell and stays broken.

Environment

• OS: Windows 11 Pro (10.0.22631), Git Bash (/usr/bin/bash, msys)
• Claude Code: reproduced across 2.1.270, 2.1.272, 2.1.273 (same session)
• Entrypoint: claude-vscode

Symptoms (two phases in one session)

Phase 1 — every Bash tool call returns only:

/usr/bin/bash: line 82: unalias: unsetenv: not found

...and the actual command does not run. This traces to the shell-language-gate preamble that runs before each command:

{ \builtin unalias -- 'unsetenv'; \builtin unset -f -- 'unsetenv'; } >/dev/null 2>&1 || true

At the same time, three shell snapshots written during this window (~/.claude/shell-snapshots/) contained a phantom line right after unalias -a:

  # Unset all aliases to avoid conflicts with functions
  unalias -a 2>/dev/null || true
+ alias unsetenv=':'
  shopt -s expand_aliases

diff against a healthy snapshot shows only that extra alias unsetenv=':' line (plus an unrelated PATH version bump). On Git Bash unsetenv is neither a builtin nor a command, so unalias unsetenv errors; the error appears to break the && chain of the composed -c script so the real command is never eval'd.

Phase 2 — after restarting the CLI on the same session, every Bash call returns:

(Bash completed with no output)

...with exit 0 and no side effects (a printf > file writes nothing; a background job's output file contains only [exited with code 0]). This looks like the session's persistent shell child died and the CLI keeps writing commands to a dead pipe. It persisted across a CLI upgrade (2.1.272 → 2.1.273) within the same session.

Key evidence that it's session-scoped

• Sibling sessions opened minutes apart on the same machine: Bash normal.
• A fresh session on the same 2.1.273 build: Bash works perfectly (this is the reliable recovery).
• Only re-opening the affected session keeps it broken.

Possible trigger

The broken session's cwd was recorded with a lowercase drive letter (c:\repos) while healthy sessions used C:\repos. The lowercase form appears right alongside both phases and correlates with a resume by an external launcher. Possibly the snapshot/shell-reset logic on resume mis-handles the drive-letter case and captures/creates a bad shell.

Repro (best-effort)

1. Windows + Git Bash, long session, cwd with a lowercase drive letter (c:\...).
2. Resume the session (--resume/--continue) one or more times.
3. Observe a snapshot capturing alias unsetenv=':', then the session's Bash wedging (first the unalias: unsetenv error, later completed with no output).

Workaround

Start a new session for the repo. Do not resume the session with the dead shell; upgrading the CLI or restarting the editor on the same session does not help.