Summary
Many command-line outputs encode meaning in leading and trailing whitespace: git status --porcelain uses the first two columns as status flags, git diff --stat pads counts, git shortlog -sn right-aligns totals. Any helper that calls .trim() on such stdout destroys that meaning before the parser ever sees it. This page records a concrete instance: a fix shipped in Claude Code 2.1.321 (2026-11-09) and its transfer to yoyo, whose git::run_git / run_git_in_dir helpers trim both ends of stdout. A related lesson from the same changelog: a failed status query must never be reported as a clean working tree.
Key Points
- Trimming is lossy for fixed-column formats.
.trim()removes the leading space that distinguishes unstaged from staged in porcelain output;.trim_end()is sufficient for nearly every log/string use case. - Claude Code 2.1.321 fixed two symptoms of the same class of bug:
- The git status given to the model at session start read as clean when the
git statuscommand itself failed; it now reads as unavailable. - The first listed file was reported as staged when its changes were in fact unstaged.
- The git status given to the model at session start read as clean when the
- yoyo exhibits the same defect (observed with the built binary in a temporary repo): stdout passes through
.trim(), so" M Cargo.toml"becomes"M Cargo.toml". - Observed user-visible effects in yoyo:
- The banner reports "1 staged, 1 modified" for two purely unstaged files.
/git stagelistsargo.toml— the path loses its first character, so staging it would fail.
- Two distinct correctness rules: never conflate query failed with nothing to report, and never let a generic string helper normalise a whitespace-sensitive protocol.