Repository navigation
Description
Describe the bug
The built-in rg tool returns incorrect filenames and line numbers when output compaction interprets numeric filename suffixes or directory components as grep field delimiters. Standalone ripgrep output launched in bash is correct.
This can misattribute search results during debugging. Distinct files can also be merged into one reported file.
Affected version
1.0.105
Steps to reproduce the behavior
Create a directory whose absolute path reaches at least 64 characters, then place the attached rg-compactor-repro.log-3.txt file into that directory and rename it to rg-compactor-repro.log-3 (strip the '.txt', I couldn't attach the file without adding that to the end). Start a new copilot session and tell it :
Validate a suspected Copilot CLI grep-output compaction bug using this existing file:
/path/to/rg-compactor-repro.log-3
Do not modify the file. Use its full absolute path: output length affects whether compaction activates. The file contains 20 identical RG_REPRO lines.
Perform these checks using the built-in rg tool (functions.rg), NOT shell ripgrep or another search tool:
1. Control: pattern="RG_REPRO", paths="<file_path>, output_mode="content", head_limit=19, -n=true.
2. Reproduction: use exactly the same arguments, except head_limit=20.
Then independently obtain the correct baseline using Bash:
rg -H -n -m 20 RG_REPRO <file_path>
Compare the literal tool responses, without silently correcting filenames or line numbers.
On the affected CLI 1.0.105 build, the control retains the filename ending in .log-3 and actual line numbers 1 through 19. The reproduction instead groups results under rg-compactor-repro.log (losing -3), gives every result apparent line number 3, and moves the real line number into the text, such as "3: 1:RG_REPRO". The Bash baseline retains .log-3 and actual line numbers 1 through 20.
Report REPRODUCED only if that corruption is observed. Otherwise report NOT REPRODUCED or INCONCLUSIVE and explain the actual results. Merely grouping results is not a failure if filenames and line numbers remain correct. Preserve the tool responses as evidence; do not assume a different CLI version has the same defect.
Ensure you update /path/to to whatever path you actually used.
What this test does it demonstrate that the built in rg tool is returning corrupt/different results than using ripgrep directly in bash.
Additional confirmed impact
• Numeric directory components can trigger the same corruption.
• Disabling line-number output still produces fabricated line numbers.
• Two files, plain.log and plain.log-3 , containing 32 matching lines each, are incorrectly reported as 64 matches across one file.
Expected behavior
built in rg tool shouldn't produce corrupt results pointing to non-existent files.
Additional context
No response
Activity
aaroneng commentedon Nov 1, 2026
Not sure if my rg-compactor-repro.log-3 file attached correctly. If it didn't it was literally just a plain text file containing 20 lines each exactly containing 'RG_REPRO'