[BUG] Windows: Grep corrupts forward slashes to backslashes in context lines when paths render relative

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?

On Windows, the Grep tool's content output converts forward slashes to backslashes inside path-like tokens on context lines (those produced by -A, -B or -C). Matched lines are unaffected.

It only happens when the search path is inside the project directory, where results render with relative path prefixes. Searching a path outside the project renders absolute prefixes and the output is correct.

Running rg directly with identical arguments always returns correct output, so the corruption is in the tool layer rather than ripgrep.

The result is indistinguishable from a genuine defect in the file being read. In my case it made a Kubernetes Ingress's annotations appear malformed (kubernetes.io\ingress.class instead of kubernetes.io/ingress.class), and I reported a non-existent bug to a colleague before opening the file directly and finding it was fine.

What Should Happen?

Context lines should reproduce file content byte-for-byte, exactly as match lines do, and exactly as rg does.

Expected output for the repro below:

1-alpha.beta.gamma/one: "1"
2-delta.epsilon.zeta/two: "2"
3:eta.theta.iota/three: "3"
4-kappa.lambda.mu/four: "4"
5-nu.xi.omicron/five: /plain/path/value

Error Messages/Logs

No error is raised. The tool returns success with silently corrupted content.

Steps to Reproduce

1. In a project directory (one Claude Code treats as the working directory), create greptest/sample.txt with exactly:

alpha.beta.gamma/one: "1"
delta.epsilon.zeta/two: "2"
eta.theta.iota/three: "3"
kappa.lambda.mu/four: "4"
nu.xi.omicron/five: /plain/path/value

1. Ask Claude to run the Grep tool with:

{
  "pattern": "three",
  "output_mode": "content",
  "-n": true,
  "-C": 2,
  "path": "<project>/greptest"
}

1. Observe the returned content:

greptest\sample.txt-1-alpha.beta.gamma\one: "1"
greptest\sample.txt-2-delta.epsilon.zeta\two: "2"
greptest\sample.txt:3:eta.theta.iota/three: "3"
greptest\sample.txt-4-kappa.lambda.mu\four: "4"
greptest\sample.txt-5-nu.xi.omicron\five: /plain/path/value

Lines 1, 2, 4 and 5 are context lines and have had / replaced with \. Line 3 is the match and is correct.

1. Compare against ripgrep with the same arguments, which is correct:

$ rg -n -C 2 three greptest
1-alpha.beta.gamma/one: "1"
2-delta.epsilon.zeta/two: "2"
3:eta.theta.iota/three: "3"
4-kappa.lambda.mu/four: "4"
5-nu.xi.omicron/five: /plain/path/value

1. Contrast case that does not reproduce: place the identical file outside the project (e.g. under C:\Users\<user>\AppData\Local\Temp\greptest) and grep it by absolute path. Every line renders correctly, including context. The only difference is that the path prefix is absolute rather than relative.

Claude Model

Opus

Is this a regression?

No — reproduces identically on 2.1.228 and 2.1.231.

Last Working Version

_No response_

Claude Code Version

2.1.231 (Claude Code)

Platform

Other

Operating System

Windows 11 Pro 10.0.26200

Terminal/Shell

VS Code extension, PowerShell 7 (pwsh)

Additional Information

Observations that may narrow it down:

• Deterministic across repeated calls and across a restart of Claude Code.
• Only -NN- context lines are affected; :NN: match lines are always correct. The same physical line renders correctly or incorrectly depending purely on whether it matched the pattern — I confirmed this by changing only the search pattern against the same file.
• On line 5 only the token before the colon is converted; the value /plain/path/value keeps its slashes. So it is not blanket whole-line normalisation — something is identifying path-like tokens (word.word.word/word) and converting them.
• Reproduces only when the path prefix renders relative, which suggests the relative-path conversion is being applied to the whole output line rather than just the prefix, and only on the context-line code path.

Possibly related, same family of Windows path-handling issues: #30736, #17501, #22060.