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

[SpikedCola]

Before submitting your bug report

• I've tried finding an answer on the Continue docs site
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Windows 7
- Continue version: v2.0.0
- IDE version: VSCodium 1.116.02821
- Model: Unsloth Studio Local

Description

The grep_search agent tool always returns "The search returned no results" on Windows, even when ripgrep finds matches. If I use Process Monitor to catch rg.exe being run, and run it manually, I get search results. If I search the same string in VSCode I also get search results.

The bug is in core/util/grepSearch.ts in formatGrepSearchResults. The parser checks for file header lines using:

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

On Windows, ripgrep outputs paths with backslashes (.\templates\foo\bar.tpl) instead of forward slashes (./templates/foo/bar.tpl). The startsWith("./") check never matches, so numResults stays 0 and all results are silently discarded despite the content being present.

I added || line.startsWith(".\\") to this check, and now I get the search results I expect.

To reproduce

1. Ask the agent to search for a string that exists in the codebase using the grep_search tool
2. Observe "The search returned no results" even though the string is present

Log output

[LHMQ878]

While looking into this I found the ./ assumption is not in one place but four — #13037 fixes the one this issue names, and I've opened #13042 for the rest.

The one I'd flag: splitGrepResultsByFile in core/tools/implementations/grepSearch.ts matches headings with /^\.\/([^\n]+)$/gm. So with splitByFile: true on Windows, fixing only the formatGrepSearchResults check moves the behaviour from "The search returned no results." to returning an empty array of context items — which reads as a successful call with nothing found, rather than as a failure. Reproduced with a control experiment (revert that one file, the test fails with expected [] to have a length of 2 but got +0).

The other two: that same function's captured path becomes a type: "file" ContextItem URI, and those are glob-matched for rule application in core/llm/rules/getSystemMessageWithRules.ts — a backslash escapes in a glob rather than separating, so src\calc.ts matches no rule pattern; and the maxResults truncation in extensions/vscode/src/VsCodeIde.ts splits on (\n--|\n\.\/), so on Windows it finds no boundaries and can't honour the limit.

Worth noting both IDE integrations pass . as the ripgrep root (VsCodeIde.ts:609, IntelliJIde.kt:488), so this isn't VS Code-specific.

@SpikedCola — the Process Monitor diagnosis in your report is what made this quick to confirm, thank you. grepSearchImpl had no test file at all, which is presumably why the other three sites went unnoticed; #13042 adds one.