The grep tool's content and count output modes always returned 'No
matches found' on Windows due to two issues:
1. Regex ^(.+?):(\d+):(.*)$ fails on Windows paths like
C:\path\file.ts:42:content because lazy .+? matches only 'C',
then \d+ fails on '\path\...'
2. ripgrep outputs CRLF line endings on Windows. After split('\n'),
trailing \r breaks the $ anchor in the regex, causing every
line to fail matching.
Fix: update parseOutput and parseCountOutput regexes to handle
drive-letter prefixes ([A-Za-z]:[\/]), and strip trailing \r
from each line before matching.
Note: PR #2976 attempted to fix (1) with --path-separator=/ but
this flag gets expanded by MSYS2/Git Bash to a full path, causing
a separate rg error. This PR avoids --path-separator entirely.
Closes#2962
The auto-download mechanism for ripgrep existed but was never called.
When 'rg' wasn't in PATH, the grep tool silently fell back to GNU grep,
which wastes ~10% token budget due to noisy results.
Changes:
1. Wired up resolveGrepCliWithAutoInstall() in the CLI resolution path
2. When 'rg' is not found in PATH, auto-downloads ripgrep v14.1.1
3. Caches the downloaded binary in OpenCode data directory
4. Falls back to GNU grep only if auto-download fails (with warning)
Fixes#3003
- Use tool.schema.enum() for output_mode instead of generic string()
- Remove unsafe type assertion for output_mode
- Fix files_with_matches mode returning empty results by adding
filesOnly flag to parseOutput for --files-with-matches rg output
- Add --threads=4 flag to all rg invocations (grep and glob)
- Add global semaphore limiting concurrent rg processes to 2
- Reduce grep timeout from 300s to 60s (matches tool description)
- Reduce max output from 10MB to 256KB (prevents excessive memory usage)
- Add output_mode parameter (content/files_with_matches/count)
- Add head_limit parameter for incremental result fetching
Closes#2008
Ref: #674, #1722
rlavkvmflzk