rtk grep calls system grep instead of ripgrep — breaks -g/--glob flags

[jbgutierrez]

Environment

• rtk 0.42.0 (Homebrew, macOS arm64)
• ripgrep 14.x installed at ~/homebrew/bin/rg

Reproduction

rtk grep -i "compact" ~/.pi/agent/ -g "*.md" -l

Expected: filters files by glob using ripgrep internally
Actual: calls /usr/bin/grep which does not support -g or --glob

grep: invalid option -- g
usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] ...

Also fails with --glob:

rtk grep -i "compact" ~/.pi/agent/ --glob "*.md"
# grep: unrecognized option `--glob`

Context

rtk rewrite correctly rewrites rg → rtk grep, but rtk grep delegates to system grep instead of ripgrep. Since the rewrite assumes ripgrep semantics, any rg-specific flags break.

Expected behavior

rtk grep should either:

1. Use ripgrep internally (since it rewrites rg commands to itself), or
2. Not rewrite rg commands that use flags incompatible with its own interface

Workaround

RTK_DISABLED=1 rg ... bypasses the rewrite.

[pszymkowiak]

wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟠 Priority	high
🎯 Confidence	93%

Summary

rtk grep delegates to /usr/bin/grep instead of ripgrep, breaking all rg-specific flags (--glob/-g, --fixed-strings, etc.) that rtk rewrite assumes will work.

---

Triaged automatically by wshm · This is an automated analysis, not a human review.

[KuSh]

Hi, rtk internally uses rg if installed but fallback to grep in case of rg error.

What does rg -n --no-heading --no-ignore-vcs -i "compact" ~/.pi/agent/ -g "*.md" -l returns on your system?
Could you also test your command without -l arg?

Thanks

[olsavmic]

Confirming this on rtk 0.42.0 (Homebrew, macOS arm64) with ripgrep 15.1.0 at /opt/homebrew/bin/rg.

The auto-rewrite hook (rtk hook claude) collapses rg into rtk grep, which then delegates rg-flags to system BSD grep:

$ rtk rewrite "rg pattern src/"
rtk grep pattern src/

$ rtk grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD     # <- not ripgrep

$ /opt/homebrew/bin/rg --version
ripgrep 15.1.0                                    # <- the real binary is fine

The breakage matches exactly:

$ rtk grep --glob '*.py' alpha .
grep: unrecognized option `--glob'

$ rtk grep -P 'alpha(?=\s)' a.py
grep: invalid option -- P

Worth flagging: this also contradicts rtk grep's own --help, which advertises the passthrough as "Extra ripgrep arguments (e.g., -i, -A 3, -w, --glob)" — but --glob is precisely what fails. The embedded rewrite rule ^(rg|grep)\s+ treats both tools as the same proxy.

Note rtk rg ... (and rtk proxy rg ...) do invoke real ripgrep correctly — so the fix could be as simple as routing the rg rewrite to rtk rg instead of rtk grep when ripgrep is present, rather than reimplementing glob/PCRE2 support in the grep proxy.

[KuSh]

@olsavmic is rg available on your PATH? What does rg --version output?

You seem to need to call it with absolute path prefix, which is not how tool discovery works in POSIX systems.

As already states, if rg is available, rtk uses it internally. Except if it fails.

Again, what does rg -n --no-heading --no-ignore-vcs -i "compact" ~/.pi/agent/ -g "*.md" -l also could you try the same command without -l arg (that could be the problem)

[olsavmic]

@KuSh

ripgrep 15.1.0

features:+pcre2
simd(compile):+NEON
simd(runtime):+NEON

PCRE2 10.45 is available (JIT is available)

The rg -n --no-heading --no-ignore-vcs -i "compact" ~/.pi/agent/ -g "*.md" -l command just works with and without -l (with a different path obviously 😄)

[KuSh]

with a different path obviously 😄

Which path? rtk uses which crate to find rg on PATH. If it runs grep that's because: 1. it can't find rg on your system 2. or the command fail for some reason.

What does rtk which rg output?