[BUG] Windows + Git Bash: statusLine/hook command paths with backslashes are silently mangled - status line never renders (root cause behind #57629)

Environment

• OS: Windows 11 Pro (10.0.26200)
• Claude Code: 2.1.215
• Shell landscape: PowerShell 7 (pwsh) as primary shell, Git for Windows (Git Bash) installed
• Terminal: Windows Terminal

TL;DR

On Windows machines that have Git Bash installed, settings.json command strings (statusLine, hooks) are executed through bash. Bash consumes backslashes in unquoted paths as escape sequences, so a typical Windows-style command like

"command": "pwsh.exe -NoProfile -ExecutionPolicy Bypass -File C:\\Users\\me\\.claude\\statusline-command.ps1"

reaches pwsh as C:Usersme.claudestatusline-command.ps1. The command fails on every invocation, and since a failing statusline command renders as nothing (an empty reserved row in the fullscreen TUI, nothing at all in default), the feature appears completely dead. On my machine this went unnoticed for months because the failure is only visible under --debug.

I believe this is the concrete root cause behind #57629 ("statusLine not rendering on Windows", closed as stale) and likely #57940 and #60386 as well. It would also explain the cross-environment observation in #57629 that the same setup works under WSL but not native Windows: WSL configs use POSIX paths, so there are no backslashes to destroy. Tool-generated configs that write native Windows paths (e.g. claude-hud's setup) would be systematically affected.

Steps to reproduce

1. On Windows with Git for Windows installed, configure a statusline with an unquoted backslash path:

``json
"statusLine": {
"type": "command",
"command": "pwsh.exe -NoProfile -ExecutionPolicy Bypass -File C:\\Users\\me\\.claude\\statusline-command.ps1"
}
``

1. Verify the script itself works: echo '{}' | pwsh.exe -NoProfile -File C:\Users\me\.claude\statusline-command.ps1 (from PowerShell) prints output and exits 0.
2. Start Claude Code, exchange a message.

Expected: status line renders.
Actual: no status line (default TUI) / blank reserved row (fullscreen TUI). claude --debug shows:

[DEBUG] StatusLine [pwsh.exe -NoProfile -ExecutionPolicy Bypass -File C:\Users\me\.claude\statusline-command.ps1] stderr: The argument 'C:Usersme.claudestatusline-command.ps1' is not recognized as the name of a script file. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
[WARN]  StatusLine [pwsh.exe -NoProfile -ExecutionPolicy Bypass -File C:\Users\me\.claude\statusline-command.ps1] completed with status 64

The mechanism is plain bash behavior, reproducible in Git Bash directly:

$ pwsh.exe -NoProfile -File C:\Users\me\.claude\statusline.ps1
The argument 'C:Usersme.claudestatusline.ps1' is not recognized as the name of a script file.

Workaround

Quote the path and use forward slashes — works immediately:

"command": "pwsh.exe -NoProfile -ExecutionPolicy Bypass -File \"C:/Users/me/.claude/statusline-command.ps1\""

Two adjacent Windows gotchas for anyone landing here from the same symptom:

• pwsh emits redirected stdout in the legacy codepage; add [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 to the script or emoji/non-ASCII render as ??.
• The script's cwd is not the session's project directory — use git -C "$dir" with workspace.current_dir from the stdin JSON.

Suggested fixes

1. Surface the failure. A statusline/hook command that fails with a non-zero exit on every invocation is a misconfiguration, not a preference — a one-time visible warning (like the existing workspace-trust skip message) would have turned months of silent breakage into a 30-second fix. The stderr is already captured; it's just only visible under --debug.
2. Docs callout on the statusline and hooks pages: on Windows with Git Bash, command strings are parsed by bash — backslash paths must be quoted/forward-slashed.
3. Optionally: detect the pattern ([A-Za-z]:\ outside quotes in a command string on Windows) and warn at settings load.

Related

• #57629 (closed stale — same symptom, root cause above)
• #57940 (closed duplicate — "command runs but line never renders")
• #60386 (closed duplicate — "output not rendered in TUI", Windows 11)