statusLine debug capture writes to a garbled filename in the current working directory instead of ~/.claude/ (Windows + Git Bash)

Environment

• OS: Windows 11
• Shell: Git Bash (MSYS)
• Claude Code version: 2.1.220 (current); reproduced across versions at least back to 2.1.42
• statusLine configured via .claude/settings.json with a PowerShell command

What happens

When Claude Code invokes the debug capture for the statusLine feature, it appears to construct an absolute Windows path for its debug output (e.g. C:\Users\<user>\.claude\debug-input.json and ...\debug-err.txt), but something in the write path mishandles the backslashes in a POSIX/bash context (Git Bash on Windows). The backslashes are treated as literal characters rather than path separators, which:

1. Collapses the intended path into a single garbled filename, e.g. a file literally named C:UsersPCPVclaudedebug-input.json (colons and backslashes stripped/mangled, sometimes with visible mojibake around the colon, e.g. CUsers...).
2. Drops that file in whatever the shell's current working directory happens to be at the time — not ~/.claude/.

Since a Claude Code session's cwd is almost always a project/repo directory (not the home directory), this means a stray C:UsersPCPV.claudedebug-err.txt / C:UsersPCPV.claudedebug-input.json pair gets silently dropped into the root of whatever repo the session is working in, essentially every time the statusline debug path fires there instead of at home.

Evidence

• debug-input.json's content is exactly the JSON payload documented for the statusLine command's stdin (session_id, transcript_path, cwd, model, workspace, version, output_style, cost, context_window), confirming which feature is writing it.
• On one long-lived dev machine, this scan turned up 93 separate repo working directories (worktrees of the same repo family) each containing a stray mangled pair, dated from roughly two months ago through the day of this report — i.e., it fires on essentially every session that has a statusLine configured, not a one-off.
• One surviving correctly placed copy at ~/.claude/debug-input.json (dated much earlier, version 2.1.42) confirms the home-directory path is the intended destination and works at least sometimes; the repo-scattered copies are the failure mode.

Impact

• Untracked junk files appear in the root of every git working tree the affected user works in.
• These can trip up tooling that expects a clean/known working tree (e.g. git worktree remove refusing to delete a worktree because of "Directory not empty" when the only untracked leftover is one of these files).
• No sensitive data appears to be in the leaked file's contents (usage/cost/session metadata only), but the path-construction bug itself seems worth fixing regardless.

Suggested direction

Whatever writes the statusline debug capture should build the target path using the platform-appropriate path join for the actual interpreter running it (Git Bash resolves Windows paths like /c/Users/<user>/.claude/..., not C:\Users\<user>\.claude\...), rather than hardcoding a Windows-style absolute path and letting it degrade into a POSIX filename.

Happy to share the exact file listing / more repro detail if useful.