Windows: Grep tool context lines starting with '/' and containing 'number:' get slashes rewritten to backslashes (false path:line detection)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 25, 2026

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.

View original on GitHub ↗