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

Status Closed — not planned
Reported on v2.1.50
Maintainer reply None cached
Activity 6 comments · opened Feb 23, 2026 · closed Apr 21, 2026

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.

View original on GitHub ↗

6 Comments

github-actions[bot] · 7 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/26614

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

LayZeeDK · 7 months ago

Not a duplicate of #22231

The auto-closer flagged this as a duplicate of #26614, which was itself closed as a duplicate of #22231. These are different bugs:

| Issue | Bug | Component |
|-------|-----|-----------|
| #22231 | Unescaped \ in shell snapshot script breaks Zsh alias | cli.js shell integration |
| #26614 / #27988 | arm64-win32 rg.exe binary treats argv[0] as regex pattern | Vendored ripgrep binary |

Fixing #22231 (escaping backslashes in the Zsh alias script) will not fix this issue. The binary itself is broken regardless of how it is invoked — confirmed by setting MSYS_NO_PATHCONV=1 and invoking the binary directly outside any shell integration.

Root cause: positional argument parsing, not the regex engine

The -e flag bypasses the bug entirely:

# Broken — positional pattern, rg reads its own path as the pattern
rg.exe "dotnet" file.yml
# -> regex parse error: (?:C:\Users\...\rg.exe) invalid hexadecimal digit

# Works — explicit -e flag
rg.exe -e "dotnet" file.yml
# -> dotnet test tests/MyApi.Test ...

Additional findings:

  • -- separator does NOT help (still reads argv[0])
  • MSYS_NO_PATHCONV=1 does NOT help (rules out MSYS path translation)
  • The system ripgrep (Chocolatey x86_64 v14.1.0, running under emulation) works correctly

Suggested fix for Claude Code

Pass the search pattern via -e when invoking ripgrep instead of as a positional argument. This is a one-line change that would fix the Grep tool on ARM64 Windows without needing to rebuild the vendored binary.

Environment

  • Device: Microsoft Surface Laptop 7 (Qualcomm Snapdragon X Elite)
  • Windows 11 Pro Build 26220
  • Shell: Git Bash (MINGW64)
  • Vendored rg: arm64-win32 v14.1.1 (rev c689721667), -pcre2, NEON SIMD
  • System rg: Chocolatey x86_64 v14.1.0, +pcre2 — works correctly under emulation
LayZeeDK · 6 months ago

Not stale. Highly relevant with big implications for Windows arm64 users since we either get slow results or risk incorrect results for the common operation of searching files/output.

github-actions[bot] · 5 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

LayZeeDK · 5 months ago

Not stale. Re-open this issue.

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.