Windows: Grep tool context lines starting with '/' and containing 'number:' get slashes rewritten to backslashes (false path:line detection)
Summary
On Windows, the built-in Grep tool's context lines (-A/-B/-C output) are corrupted in the rendered tool result: when a context line starts with / AND contains a number followed by : anywhere in the line, all slashes in the leading run are rewritten to backslashes. The line appears to be mis-detected as a path:line reference and gets Windows path-separator normalization applied to non-path content.
Files on disk are untouched — this is display/result-rendering only. But the model receives the corrupted text as the tool result, so it can misread source files (e.g. CSS comments appear to start with \* instead of /*) and could propagate the corruption into edits or quotes.
Match lines are unaffected — only context lines are corrupted.
Environment
- Claude Code 2.1.243, Windows 11 Pro 10.0.26200
- Tool: built-in Grep (
output_mode: "content"with-A/-B/-C)
Minimal reproduction
Create a file probe.css:
MATCHX
filler
/* foo 24: bar
x
Run the Grep tool: pattern MATCHX, output_mode: "content", -A: 4 on that file.
Expected (context line intact):
1:MATCHX
2-filler
3-
4-/* foo 24: bar
5-x
Actual (leading / rewritten to \):
1:MATCHX
2-filler
3-
4-\* foo 24: bar
5-x
Characterization (bisected via probe files)
| Context line content | Rendered as | Corrupted? |
|---|---|---|
| /* foo 24: bar | \* foo 24: bar | ✅ yes |
| /one/two/three foo 24: bar | \one\two\three foo 24: bar | ✅ yes — the entire leading slash run is flipped |
| /* foo x24 bar (no number:) | unchanged | ❌ no |
| no leading slash but has 24: here | unchanged | ❌ no |
| Same content as a match line (NN: prefix) | unchanged | ❌ no |
Trigger = leading / AND \d+: anywhere in the line, on context lines only. Independent of: file extension, path (spaces or not), line endings (LF verified), pattern used, multibyte content.
Real-world impact
CSS files are the classic victim — comments like /* AA fix 2026-08-24: ... */ or /* contrast is 3.8:1 ... */ hit the trigger constantly (2026-08-24: and 3.8:1 both contain number:). In a Dawn/Shopify theme repo with annotated CSS, a large share of context-line output around comments is corrupted, and the model has to re-Read files to get trustworthy text.
Related
Likely the same underlying path-normalization/rendering family as #17501 and #45940 (backslash handling in Windows output rendering), but this report is specifically about the Grep tool mis-detecting non-path context lines as path:line references and rewriting their content.