Skip to content

fix(core): recognise Windows backslash paths in grep_search output - #13037

Open
guillaume-flambard wants to merge 2 commits into
continuedev:mainfrom
guillaume-flambard:fix/grep-search-windows-backslash-13027
Open

fix(core): recognise Windows backslash paths in grep_search output#13037
guillaume-flambard wants to merge 2 commits into
continuedev:mainfrom
guillaume-flambard:fix/grep-search-windows-backslash-13027

Conversation

@guillaume-flambard

Copy link
Copy Markdown

Problem

Fixes #13027.

grep_search always returns "The search returned no results" on Windows, even when ripgrep finds matches (verified by the reporter with Process Monitor: rg.exe runs and returns results, but the tool reports none).

Root cause

formatGrepSearchResults in core/util/grepSearch.ts detects ripgrep file-heading lines with:

if (line.startsWith("./") || line === "--") {

ripgrep emits headings as the relative path — ./dir/file on POSIX, but .\dir\file on Windows. The startsWith("./") check never matches the Windows form, so no line is counted as a heading, numResults stays 0, and every match is silently discarded. Diagnosed precisely in the issue by @SpikedCola.

Fix

Also accept the .\ prefix:

if (line.startsWith("./") || line.startsWith(".\\") || line === "--") {

POSIX ./ headings and the -- context separator are unchanged.

Tests

Added a unit test in core/util/grepSearch.vitest.ts that feeds backslash-separated ripgrep output and asserts numResults > 0 and the filenames are present — it fails before the change (0 results) and passes after.

I verified the header-detection logic in isolation (the Windows heading goes from unrecognised → recognised, POSIX and -- still recognised). I don't have a Windows machine to run the full agent end-to-end, but the parser is pure and the added test covers the regression in CI.

`formatGrepSearchResults` detected ripgrep file headings with
`line.startsWith("./")`. On Windows ripgrep emits `.\dir\file` instead of
`./dir/file`, so no line was ever recognised as a heading, `numResults` stayed
0, and every match was silently discarded — grep_search always returned "no
results" on Windows even though ripgrep found matches.

Also accept the `.\` prefix. POSIX `./` headings and the `--` context
separator are unchanged. Adds a unit test covering backslash-separated output.

Fixes continuedev#13027
@guillaume-flambard
guillaume-flambard requested a review from a team as a code owner July 27, 2026 11:45
@guillaume-flambard
guillaume-flambard requested review from sestinj and removed request for a team July 27, 2026 11:45
@github-actions

github-actions Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@SpikedCola

Copy link
Copy Markdown

I have read the CLA Document and I hereby sign the CLA

1 similar comment
@guillaume-flambard

Copy link
Copy Markdown
Author

I have read the CLA Document and I hereby sign the CLA

@guillaume-flambard

Copy link
Copy Markdown
Author

Heads-up on CI: jetbrains-tests is red here, but it's red on every other open PR right now too (#13036, #13034, #13033, #13032, #13031) — a pre-existing failure unrelated to this change. This PR only touches core/util/grepSearch.ts (pure TS parsing); core-checks, which runs the grep unit tests including the new backslash-path case, is green. The build-and-upload-vsix (darwin) cancel and require-all-checks-to-pass failure are both cascades from that jetbrains job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

grep_search tool returns no results on Windows due to backslash path separator in ripgrep output

2 participants