[BUG] gitStatus context trims leading whitespace from git status --short, hiding staged vs. unstaged distinction

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The gitStatus section injected into the conversation context at session start trims leading (and presumably trailing) whitespace from git status --short output. This prevents Claude from correctly distinguishing staged changes (M file) from unstaged changes ( M file), because both render as M file after trimming. Technically, Claude could check for two spaces after the M to remove the ambiguity, but it does not.

Steps to Reproduce

1. In a git repo, modify a file without staging it (so git status --short shows M file)
2. Start a new Claude Code session
3. Observe the gitStatus context -- the leading space before M is stripped

For example, with two modified-but-unstaged files:

Actual git status --short output:

 M some/dir/somefile.txt
 M another/dir/file.sh

What appears in gitStatus context:

M some/dir/somefile.txt
 M another/dir/file.sh

The leading space on the first file is stripped, making it look like it's staged (index column) rather than unstaged (working tree column). The second file retains its leading space, so the inconsistency suggests a trimming bug that hits the first line of the status output.

What Should Happen?

The git status --short column positions should be preserved verbatim in the gitStatus context, since the two-character XY prefix is how staged vs. unstaged changes are distinguished.

Claude Model

Opus 4.6

Claude Code Version

2.1.91

Platform

macOS (Darwin 25.3.0)

Terminal/Shell

Terminal.app
bash 5.3.9(1)-release