[BUG] Grep content output: text before the first colon of context lines is path-normalized on Windows (single-file searches; '//' becomes '\')

Independently reproduced on Windows (Claude Code 2.1.227, so still present after 2.1.220) — but on a plain Java comment with no URL in it, which led us to a broader trigger characterization and a mechanism that explains every observation in this report, including the match/context asymmetry. Suggest retitling accordingly (proposal at the end).

Our corrupted line (real file, hit twice in unrelated sessions five days apart, byte-identical mangle both times):

// Frozen bookkeeping lines, not kitchen work (JC-400): the OrderItem constructor

rendered as a context line:

\ Frozen bookkeeping lines, not kitchen work (JC-400): the OrderItem constructor

No scheme:// anywhere — the only colon is (JC-400):. So the URL condition doesn't hold. Isolating with synthetic files gives:

Corrected trigger

A Grep content output line is corrupted iff all of:

1. It's a context line (-A/-B/-C).
2. The search runs in single-file mode (path is a file, so rg omits the filename prefix). Directory mode is immune — see mechanism.
3. The line contains a colon, with at least one forward slash before the first colon.

The transformation: in the segment before the first colon, every run of / becomes a single \ (//→\, ///→\, /*→\*, a/b→a\b). Everything from the first colon onward is untouched. Two corrections to the OP's narrowing:

• scheme:// is not required — any colon works. The 2×2 matrix above confounds the two variables: every URL-bearing doc comment has http: as its first colon with the leading /// before it, and every "no URL" control line also had no colon at all.
• The slash-run need not be leading: a/b: c/d: e/f → a\b: c/d: e/f (only the slash before the first colon flips). The OP's string-literal control (private static … "http://…") rendered clean not because the slashes weren't leading, but because no slash precedes its first colon (http:).

All eight clean/corrupt cases in the OP's isolation table are consistent with this rule.

Mechanism: first-colon path split

The behavior is exactly what you'd get from post-processing that splits each rg output line at its first colon, treats the left segment as a file path, Windows-normalizes it (/→\, collapse duplicate separators), and reassembles:

| Output shape | First colon lands on | Effect |
|---|---|---|
| Single file, match line: 710:content | the line-number separator | "path" segment is digits — no visible change |
| Single file, context line: 710-content | a colon inside file content | everything left of it is path-normalized → corruption |
| Directory mode, any line: C:\dir\file.cs:1:content / C:\dir\file.cs-2-content | the drive-letter colon (C:) | "path" segment is just C — shielded |

So match lines aren't handled more carefully — the same normalization apparently runs on every line, but only on single-file context lines does the first colon fall inside user content. The drive-letter shield explains why directory searches (the common case) never show it, and why the bug survived unnoticed; verified empirically — the same test file corrupts when grepped by file path and renders clean when the same query runs with path set to its parent folder. It also predicts POSIX is silently near-immune (no drive colon, but normalizing to / is mostly idempotent — though //→/ collapsing may be observable there).

Not ripgrep

System ripgrep 14.1.1 with identical arguments produces correct bytes for the same file (verified via hexdump of both the file and rg's output). The session transcript .jsonl contains the corrupted string inside the recorded tool_result (verified via hexdump: file has 2f 2f 20, transcript has 5c 5c 20 = JSON-escaped \), so the rewrite happens in Claude Code's post-processing between rg's stdout and the tool result.

Minimal repro (Windows)

printf 'MATCH ANCHOR\n// first: mid/dle: last\na/b: c/d: e/f\n// no colon so untouched\n' > t.txt

Grep tool call: {"pattern": "MATCH ANCHOR", "path": "C:\\...\\t.txt", "output_mode": "content", "-n": true, "-A": 3}

Observed:

1:MATCH ANCHOR
2-\ first: mid/dle: last
3-a\b: c/d: e/f
4-// no colon so untouched

Line 2: leading // collapsed to \; mid/dle (after the first colon) intact. Line 3: mid-line slash flips, but only before the first colon. Line 4: no colon → untouched. Same query with path = containing folder → all lines correct.

Fix implication

Any first-colon split of rg's human-readable output is ambiguous by construction (drive letters, colons in content, dashes in filenames). Parsing rg --json would eliminate the guessing entirely; short of that, context lines follow the dash grammar (path-line-content) and single-file output has no path prefix to normalize at all.

Suggested retitle: [BUG] Grep content output: text before the first colon of context lines is path-normalized on Windows (single-file searches; '//' becomes '\')

@chkwok I've retitled the issue. Interesting findings you've come with. Hope this can be fixed soon

I put Fable / Opus (when it hit safeguards) to work to verify the findings. Here's what it found:

---

Follow-up: located the actual code in the bundled JS (Windows native install, claude.exe 2.1.227). It confirms the first-colon-split mechanism, and corrects one claim in my previous comment — directory-mode searches are not immune in general.

The code

From the Grep tool's call(), the output_mode: "content" branch (symbols are minified; deobfuscated names are mine):

if (output_mode === "content") {
  const { items, appliedLimit } = paginate(rgLines, head_limit, offset);
  const out = items.map((line) => {
    const start = /^[A-Za-z]:/.test(line) ? 2 : 0;   // skip a Windows drive letter
    const colon = line.indexOf(":", start);          // FIRST colon after it
    if (colon > 0) {
      const head = line.substring(0, colon);         // assumed to be a file path
      const tail = line.substring(colon);
      return toRelative(head) + tail;                // `odr` in the bundle
    }
    return line;
  });
  ...
}

function toRelative(p) {                             // `odr`
  const rel = path.relative(cwd(), p);
  return rel.startsWith("..") ? p : rel;
}

The intent is clearly display-relativization: turn C:\abs\path\File.cs:343:content into File.cs:343:content. The bug is that the "is this a path" assumption holds only for match lines in directory mode. It fails for:

• context lines — the grammar is path-line-content (dashes), so the first colon found is one inside the file content;
• single-file mode — rg emits no filename prefix at all, so the "path" is <lineno><sep><content>.

The rewrite itself is path.win32.relative, which resolves and normalizes: runs of / collapse to a single \. Hence //→\, ///→\, /*→\*, a/b→a\b, and only before the first colon.

Correction: directory mode is not immune

I previously attributed directory-mode immunity to the drive-letter colon. Wrong on two counts. The drive-letter skip is explicit in the code (start = 2), so the scan still finds a content colon; and what actually saved my earlier test was the rel.startsWith("..") fallback — the test file sat on a different root than the cwd, so path.relative produced a ..\..-prefixed string and the original line was returned untouched.

Put the same file under the cwd and directory mode corrupts too. With cwd C:\proj, test file C:\proj\sub\t.txt containing the four lines below, and Grep {pattern: "MATCH ANCHOR", path: "C:\\proj\\sub", output_mode: "content", "-n": true, "-A": 3}:

sub\t.txt:1:MATCH ANCHOR
sub\t.txt-2-\ first: mid/dle: last
sub\t.txt-3-a\b: c/d: e/f
C:\proj\sub\t.txt-4-// no colon untouched

Line 4 is the tell: with no colon in the content, colon > 0 fails, the line is returned verbatim — and so its path is left absolute while every other line got relativized. So the same defect that corrupts content also makes path rendering inconsistent within a single result block, in the exact cases where it doesn't corrupt.

Corrected condition set — a content line is rewritten iff it contains a colon (past a leading drive letter) with at least one / before it, and path.relative(cwd, head) doesn't escape upward. That covers context lines in both modes, and is why in-repo searches (the common case) are the exposed ones.

Suggested fix

Parse rg --json instead of the human-readable stream — path, line number, and text arrive as separate fields, so no grammar guessing and the relativization applies to path alone. If the text stream must be kept: relativize only when a filename prefix is actually present (i.e. not single-file mode), split on the correct separator for the line kind (: for match, - for context), and bound the path candidate to the prefix rg emitted rather than "everything before the first colon". Note output_mode: "count" has the analogous lastIndexOf(":") split; it's safe for path:count output but rests on the same assumption.

Repro cost is one file and one tool call:

printf 'MATCH ANCHOR\n// first: mid/dle: last\na/b: c/d: e/f\n// no colon untouched\n' > sub/t.txt

and the fix is testable against those four lines — line 2 (leading //), line 3 (mid-line /), line 4 (no colon, path must still relativize), plus any match line as control.

Opus on WSL/Linux

---

Cross-platform confirmation: this is not Windows-specific. Reproduced on Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2, x86_64) with Claude Code 2.1.231 — so still present four versions past the build I disassembled above.

The symptom differs exactly as the code predicts, because path.posix.normalize collapses separator runs rather than converting them. Instead of // → \, runs of forward slashes before the first colon are collapsed to a single /.

Same seven-line synthetic fixture, placed under the cwd, output_mode: "content", -n: true, -A: 6, directory mode (cwd /home/user, fixture greptest/fixture.txt):

greptest/fixture.txt:1:MATCH ANCHOR
greptest/fixture.txt-2-/ triple slash then colon: tail
greptest/fixture.txt-3-/ double slash then colon: tail
greptest/fixture.txt-4-/ single slash then colon: tail
greptest/fixture.txt-5-a/b: c/d: e/f
/home/user/greptest/fixture.txt-6-// no colon in this line at all
greptest/fixture.txt-7-plain text with colon: but no slash before it

On disk, lines 2–4 begin ///, //, and / respectively (verified with xxd: 2f 2f 2f, 2f 2f, 2f). Lines 2 and 3 are corrupted; line 4 is not.

What each line establishes:

• Line 4 is the discriminator. A lone / survives while // and /// both become /. That is separator-run collapse inside path.normalize, not a general rewrite — and it rules out any "leading slashes are stripped" reading of the Windows evidence.
• Line 6 has no colon anywhere, so the colon > 0 branch never runs and the line is returned verbatim — leaving its path absolute while every sibling line is relativized. The predicted rendering inconsistency, visible in one output block, on POSIX as on Windows.
• Line 7 shows the full extent of the mistake: the string handed to path.relative was /home/user/greptest/fixture.txt-7-plain text with colon — path, line number, dash separator, and eleven words of file content, all treated as a single path. It escaped visible damage only because it happens to contain no multi-slash run.
• Match lines are clean (control: same file, pattern: "colon", no context flag). The first colon follows the line number, so head is "2" and path.relative(cwd, "2") is "2" — content never enters the substring. Confirms the split is safe for path:line:text and unsafe for path-line-text.

Single-file mode reproduces identically. Running the same three searches through rg directly produced byte-correct output, so the corruption is in the tool's post-processing, not ripgrep.

Reproduction conditions carry over unchanged: the line must appear as a context line, and the fixture must sit under the cwd — otherwise path.relative returns a ../..-prefixed string, the startsWith("..") fallback returns the line untouched, and the bug hides. A fixture in /tmp while cwd is elsewhere gives a false negative.

One extra prerequisite on this build, worth flagging for anyone re-running it: the Grep tool has to actually be in the session's tool list. It was not there by default in the Linux native build and had to be requested explicitly at launch (claude --tools ...,Glob,Grep,...) — cf. the 2.1.162 CHANGELOG entry, "explicitly listing Grep/Glob now provides the dedicated search tools on native builds with embedded search (previously these names were silently ignored)", and #52121. Without it the model silently falls back to rg/grep through Bash, which bypasses the post-processing entirely and produces byte-correct output — i.e. a clean-looking false negative. Availability appears to vary by build/configuration (the Windows session used for the analysis above had Grep by default, launched with no --tools flag), so this is worth checking first rather than assuming.

That may also be part of why the defect has gone unnoticed: on builds where the dedicated tool isn't handed out by default, the corrupting path is exercised far less often — but where it is available, nothing distinguishes its output from ground truth.

Practical impact on Linux is the same class as on Windows, and hits the majority comment syntax: // and /// prefixed lines in C, C++, C#, Java, Rust, Go, and JavaScript are silently altered whenever they appear as context lines, with nothing in the output indicating the text differs from disk.

Implication for the fix: whatever lands must not be gated on Windows. The rg --json route fixes both platforms at once; a separator-aware split would need to be applied unconditionally.

On the title — entirely your call, and no urgency, since the tool-availability point above means most sessions never hit this at all. But if you do end up editing it again, the parenthetical has drifted from what we now know: it isn't Windows-only, isn't limited to single-file searches, and on POSIX the result is / rather than \. Something like "text before the first colon of context lines is path-normalized, corrupting source text (Windows and Linux)" would cover it. The scope caveats matter less than the fact that the corruption is silent wherever the tool is available.