claude-code - 💡(How to fix) Fix Docs/bug: statusLine.command silently fails on Windows when path contains unquoted backslashes (Git Bash interaction)

Summary

On Windows installations where Git Bash is present in PATH (very common — installed with Git for Windows), a statusLine.command that contains an unquoted Windows-style path is silently corrupted before invocation. The status line never renders, the command is never observably "run" from the user's perspective, and there's no diagnostic in /status or /doctor to indicate the failure.

Affects: Claude Code 2.1.143 on Windows 11 (10.0.22000.2538) with Git Bash in PATH. Likely affects any version where statusLine commands are spawned through bash on Windows.

Reproduction

1. On a Windows machine with Git Bash installed (so bash.exe resolves on PATH), add to ~/.claude/settings.json:

   "statusLine": {
     "type": "command",
     "command": "node C:\\Users\\<you>\\.claude\\statusline.mjs"
   }

   where statusline.mjs is any working script that writes to stdout.

2. Start claude in PowerShell. Send a message.

3. Expected: Status line at the bottom of the prompt shows the script's output.

4. Observed: No status line. /status does not mention statusLine. No error is surfaced. The script is never invoked (verifiable by instrumenting the script to append to a log file on entry — the log stays empty).

Root cause

Per the settings.json schema, statusLine.command "runs through a shell (bash on POSIX, PowerShell on Windows without Git Bash)." On a Windows host with Git Bash in PATH, the shell selected is bash, which then interprets the command string. Bash treats \ in unquoted strings as escape characters:

• Original: C:\Users\<you>\.claude\statusline.mjs
• \U → U, \s → s, \. → ., \c → c, \m → m
• Resulting path passed to node: C:Users<you>.claudestatusline.mjs (no separators left)
• node fails to find the file, exits silently.

Confirmed empirically by:

• Instrumented script never appended to its trace log when invoked via Claude (proving Claude's spawn never reached the script).
• Replacing the command with cmd /c echo STATUSLINE_WORKS produced ECHO is on. — Windows cmd's exact output when invoked with echo and no argument, proving the trailing token was lost in bash tokenization.
• Replacing with cmd /c "node C:\\..." produced the Microsoft Windows banner and a C:\Users\<you>\...> prompt as the status-line content — proving Git Bash MSYS2 path-conversion translated the /c argument to C:\, leaving cmd.exe to start in interactive mode.

Working fix (user-side)

Quoting the script path inside the JSON string survives bash's tokenizer:

"statusLine": {
  "type": "command",
  "command": "node \"C:\\Users\\<you>\\.claude\\statusline.mjs\""
}

After JSON decoding, the command is node "C:\Users\<you>\.claude\statusline.mjs" — bash preserves the contents of the double-quoted string verbatim, and Node receives the correct path.

Suggested fix in Claude Code

Two non-exclusive options, in priority order:

1. Docs: The statusLine section of the public settings reference, and the schema description, should explicitly warn Windows + Git Bash users to wrap Windows paths in double quotes inside the JSON string, and include the working example above. Today the schema description doesn't mention shell selection on Windows or this gotcha.

2. Diagnostics: When statusLine.command exits non-zero or produces no output for N consecutive invocations, surface a one-time warning in /status (e.g. statusLine: configured but last 5 invocations exited 1 — check the command). Currently silent failure is indistinguishable from "feature disabled," which makes this defect class very hard to self-diagnose.

3. Optional: Default to spawning statusLine.command through cmd.exe /d /s /c on Windows regardless of Git Bash presence, with explicit opt-in to bash via a shell field (the schema already has this for hook commands — extending it to statusLine would resolve the asymmetry).

Side note — padding: 0

During debugging I initially suspected padding: 0 was the disqualifier. The schema confirms padding is a valid number field, so this was a red herring. The two effects (no padding, no rendering) coincidentally happened together while testing two changes at once. The real defect is the unquoted-path issue above; padding: 0 is fine.

Environment

• OS: Windows 11 Pro 10.0.22000.2538
• Claude Code: 2.1.143 (native binary)
• Node: v24.15.0
• Git Bash: bundled with Git for Windows (mingw64)
• Shell used to launch claude: PowerShell