[BUG] Grep tool completely non-functional on Windows ARM64 — ripgrep arm64-win32 binary injects its own path as regex pattern

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?

The Grep tool returns "No matches found" for every query against every file on Windows ARM64. It is 100% non-functional — no content search works at all.

Root Cause

The vendored arm64-win32/rg.exe binary is treating its own executable path (C:\Users\...\rg.exe) as a regex pattern. The backslashes in the Windows path are parsed as regex escape sequences (e.g., \U as a hex digit), causing an immediate parse failure:

rg: regex parse error:
    (?:C:\Users\username\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\vendor\ripgrep\arm64-win32\rg.exe)
           ^
error: invalid hexadecimal digit

This happens on every invocation, even the simplest case:

echo "hello world" > /tmp/test.txt
"<path-to>/vendor/ripgrep/arm64-win32/rg.exe" "hello" /tmp/test.txt
# Result: regex parse error (NOT "hello world")

The x64-win32/rg.exe binary does not have this bug — it works correctly under x64 emulation on the same machine:

"<path-to>/vendor/ripgrep/x64-win32/rg.exe" "hello" /tmp/test.txt
# Result: hello world  ✓

Impact

• The Grep tool silently fails (returns "No matches found" instead of surfacing the error), so the user has no indication anything is wrong.
• Claude trusts the empty result and gives incorrect answers (e.g., "this library is not used in the project" when it actually is).
• Glob and Read tools work fine, so file discovery by name works but content search is completely broken.
• The ripgrep.node native binding appears to have the same issue (the Grep tool uses this, not the CLI).

What Should Happen?

The Grep tool should return matching content from files, identical to how it works on x64 Windows, macOS, and Linux.

The vendored arm64-win32/rg.exe should not inject its own executable path into the regex engine. At minimum, if ripgrep fails with an error, the Grep tool should surface that error to the user instead of silently returning "No matches found."

Error Messages/Logs

rg: regex parse error:
    (?:C:\Users\username\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\vendor\ripgrep\arm64-win32\rg.exe)
           ^
error: invalid hexadecimal digit

Steps to Reproduce

1. Install Claude Code 2.1.50 on a Windows 11 ARM64 device (e.g., Qualcomm Snapdragon / Surface Laptop 7)
2. Open any git repository in Claude Code
3. Use the Grep tool to search for any pattern in any file (e.g., search for "export" in any .ts file)
4. Observe: always returns "No matches found" regardless of the pattern or file

Direct CLI reproduction (confirms the binary itself is broken):

# ARM64 build — broken (argv[0] leaks into regex)
echo "test" | "<claude-code-install>/vendor/ripgrep/arm64-win32/rg.exe" "test"
# -> regex parse error: (?:C:\Users\...\rg.exe) invalid hexadecimal digit

# x64 build — works correctly under emulation on the same machine
echo "test" | "<claude-code-install>/vendor/ripgrep/x64-win32/rg.exe" "test"
# -> test

Key observations:

• Glob tool works fine (finds files by name pattern)
• Read tool works fine (reads file contents)
• Only Grep (content search via ripgrep) is broken
• The ripgrep.node native binding has the same issue as the CLI rg.exe

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.50 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Environment Details

• Device: Surface Laptop 7 (Qualcomm Snapdragon ARM64)
• Windows: 11 Enterprise, Build 26200
• Shell: Git Bash (MINGW64_NT-10.0-26200-ARM64)
• ripgrep binary: vendor/ripgrep/arm64-win32/rg.exe — 14.1.1 (rev c689721667), features: -pcre2, NEON SIMD
• ripgrep.node: vendor/ripgrep/arm64-win32/ripgrep.node — native Node addon, also affected

Suggested Fixes

1. Fix the arm64-win32 ripgrep build — the binary itself has a bug where the executable path leaks into regex parsing (argv[0] treated as pattern).
2. Fall back to x64-win32 on ARM64 — the x64 binary works perfectly under Windows' built-in x64 emulation. This would be an immediate workaround.
3. Surface the ripgrep error — currently the Grep tool silently swallows the error and returns "No matches found". At minimum, the underlying error should be visible so users know search is broken.

Workaround

Use git grep via the Bash tool instead of the Grep tool:

git grep "pattern" -- "path/"

This bypasses ripgrep entirely and works correctly.