fix(core): handle Windows separators in the remaining grep_search parsers

[LHMQ878]

Description

Follow-up to #13027. This is complementary to @guillaume-flambard's #13037, not a replacement — that PR fixes the one site the issue named, this one covers the three that were left, including a worse variant of the same bug.

ripgrep is invoked with . as the search root, so with --heading it echoes that root back on every file-heading line using the platform separator: ./path on POSIX, .\path on Windows. Four independent parsers of that output assumed ./:

#	Site	Effect on Windows	Covered by
1	core/util/grepSearch.ts:60 — formatGrepSearchResults heading check	numResults stays 0 → "The search returned no results."	#13037 (and here, refactored into a shared helper)
2	core/tools/implementations/grepSearch.ts — splitGrepResultsByFile heading regex + strip regex	With splitByFile: true, returns an empty array of context items — not even the "no results" message	this PR
3	Same function — captured path becomes a type: "file" ContextItem URI	Backslash path breaks glob rule-matching	this PR
4	extensions/vscode/src/VsCodeIde.ts:620 — maxResults truncation matchAll	No boundaries found → the result limit cannot be honoured	this PR

Site 2 is the one worth flagging: fixing only site 1 makes splitByFile: true go from "no results" to silently returning zero context items, which reads as success to the caller. Verified by control experiment below.

Site 3 is a consequence of fixing site 2 rather than extra scope. That captured path is consumed as a file ContextItem URI, which core/llm/rules/getSystemMessageWithRules.ts:288-290 glob-matches to decide which rules apply — and in a glob a backslash escapes the next character rather than separating segments, so src\calc.ts would match no rule pattern. It is normalised to forward slashes.

Both IDE integrations pass . as the ripgrep root (extensions/vscode/src/VsCodeIde.ts:609, extensions/intellij/.../IntelliJIde.kt:488), so both feed .\ into the shared core parser on Windows — this is not VS Code-specific.

To stop the four sites from drifting apart again, the predicate and its regex equivalent now live together in core/util/grepSearch.ts:

export function isGrepResultPathLine(line: string): boolean {
  return line.startsWith("./") || line.startsWith(".\\");
}

/** Regex source for the same prefix, for callers that need it inside a larger pattern. */
export const GREP_RESULT_PATH_PREFIX_SOURCE = "\\.[\\\\/]";

If #13037 lands first, site 1 here is a trivial conflict — happy to rebase onto it and drop that hunk, or to have this rebased however you prefer.

Tests

core/util/grepSearch.vitest.ts — 4 added (9 → 13):

• formats Windows-style backslash headings — nested .\src\test.kt alongside -- separators
• counts Windows headings so results are not reported as empty — asserts the reported symptom directly
• handles mixed separators in a single result set — multi-root workspaces concatenate one ripgrep run per directory
• does not treat a bare relative path as a heading — negative case: a content line starting with . (.method(), ...spread) must not open a new result

core/tools/implementations/grepSearch.vitest.ts — new file, 5 tests. grepSearchImpl had no test file at all, which is why sites 2–4 went unnoticed. Covers POSIX and Windows for both splitByFile modes, the URI normalisation, and that a genuinely empty search still reports empty.

Reviewer test plan

cd core
npx vitest run util/grepSearch.vitest.ts tools/implementations/grepSearch.vitest.ts

→ 18 passed (13 + 5).

Control experiment — do the tests actually catch the bug?

Reverting each source file in isolation, leaving the tests in place:

git stash push -- core/util/grepSearch.ts
cd core && npx vitest run util/grepSearch.vitest.ts

→ 3 fail (expected 1 to be 3, expected +0 to be 1, expected 1 to be 2); the 4th is the negative case, which correctly still passes.

git stash push -- core/tools/implementations/grepSearch.ts
cd core && npx vitest run tools/implementations/grepSearch.vitest.ts

→ 1 fail: expected [] to have a length of 2 but got +0 — the empty-array symptom, reproduced.

Regression / lint

• npx vitest run tools/ util/ — 356 passed, 16 failed. Clean main baseline on the same machine: 347 passed, 16 failed. Identical failure set (pre-existing POSIX path assumptions in resolveWorkingDirectory.vitest.ts and 3 other files, unrelated to grep); my change adds +9 passing and 0 failures.
• npx tsc --noEmit -p core — 151 errors, and clean-main baseline is also 151 (unbuilt @continuedev/* workspace packages). No new errors; grep -c grepSearch on the output → 0.
• npx eslint --max-warnings 0 on all changed files — clean. npx prettier --check — "All matched files use Prettier code style!"

Tested on

Platform	Unit tests	Real ripgrep end-to-end
Windows 11	✅	⚠️ not run
macOS / Linux	⚠️ not run	⚠️ not run

Not validated: the extension end-to-end with a live rg.exe, and the IntelliJ path. The parsers are pure functions and the tests feed them the exact byte sequences ripgrep emits, but I have not watched a real search return results in the UI. Worth a maintainer sanity-check on a Windows box before merge.

Screen recording or screenshot

N/A — no UI change; this is parser behaviour covered by unit tests.

Checklist

• I've read the contributing guide
• The relevant docs, if any, have been updated or created — none apply
• The relevant tests, if any, have been updated or created

Credit to @SpikedCola for pinpointing the root cause in #13027 with Process Monitor, and to @guillaume-flambard for #13037.

[github-actions]

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

[LHMQ878]

CI status

All 12 test jobs pass, including test (windows-latest, {18,20,22,24}) — which is the platform this PR is about, and more than I could verify locally.

Two red checks, neither caused by this PR:

• jetbrains-tests — Autocomplete > testAutocomplete() FAILED at Autocomplete.kt:42. Same failure on fix(core): recognise Windows backslash paths in grep_search output #13037 (2 files, core parser only) and on fix: composer input overflow with long unbroken strings #13039 (a GUI overflow fix), so it's failing on main independently of the change. This PR touches no autocomplete code.
• require-all-checks-to-pass — aggregate of the above plus the CLA check; nothing of its own.
• CLAAssistant — on me, will sign.

So the only thing standing between this and green is the CLA.

[LHMQ878]

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

[LHMQ878]

CI, final state

CLAAssistant now ✅. The two remaining red checks are a single pre-existing failure and its aggregator — quantified so you don't have to dig:

jetbrains-tests is failing on every branch, not just this one. Across the last 15 PR Checks runs on the repo: 0 success, 13 failure, 2 cancelled. That includes six Snyk dependency-bump branches (snyk-fix-*), which touch no application code at all, plus mcp-variable-interpolation, fix/composer-input-overflow, and both of #13037's runs. The failure is always the same assertion:

Autocomplete > testAutocomplete() FAILED
    Caused by: org.opentest4j.AssertionFailedError at Autocomplete.kt:42
> Task :testIntegration FAILED

This PR touches no autocomplete code — it changes three ripgrep-output parsers and adds tests.

require-all-checks-to-pass is purely the aggregator. Its own log shows 10 of its 11 required jobs at "result": "success" and exactly one at "result": "failure" — jetbrains-tests. No independent failure of its own.

Everything attributable to this change is green, including all 12 test jobs across ubuntu/macos/windows × Node 18/20/22/24.

(Separately: Autocomplete.kt:42 looks worth its own issue if you aren't already tracking it — it's been red for at least 15 consecutive runs, so require-all-checks-to-pass can't go green for any contributor right now. Happy to file one if that's useful, but I didn't want to bundle an unrelated report into this PR.)

[LHMQ878]

The two red checks here are not from this PR, and I'd rather say so with the evidence than leave them looking like mine.

jetbrains-tests fails, and require-all-checks-to-pass is red only because it aggregates that one. The failure is a single IntelliJ UI integration test:

Autocomplete > testAutocomplete() FAILED
    com.intellij.ide.starter.driver.engine.DriverWithContextError at Autocomplete.kt:24
        Caused by: org.opentest4j.AssertionFailedError at Autocomplete.kt:42
1 test completed, 1 failed

I checked whether it is specific to this branch by tallying the same check across the 25 most recently updated PRs in the repo:

jetbrains-tests: 20 failure, 2 cancelled, 1 success

The failures include documentation-only PRs (#13066, #12579), which cannot affect autocomplete behaviour, and PRs touching unrelated areas of the GUI, the CLI and provider code. This PR changes grep_search output parsing in core/; it does not touch the JetBrains extension or the autocomplete path.

Nothing here needs doing on my side, but two things may be worth knowing: with jetbrains-tests red repo-wide, require-all-checks-to-pass is red on essentially every open PR, so the gate currently does not distinguish a passing branch from a failing one. The log also shows the run starting from a cold Gradle cache each time (Failed to restore gradle-home-v1... Cache service responded with 400), which may or may not be related to the flake.

Happy to rebase once it's green if that helps confirm the branch itself passes.

[LHMQ878]

The red jetbrains-tests here is not from this PR, and require-all-checks-to-pass is red only because it gates on it.

jetbrains-tests failed on this PR's base commit (5522c6f4) before this branch existed:

GET /repos/continuedev/continue/commits/5522c6f4/check-runs?check_name=jetbrains-tests
  1 run: completed / failure / 2026-07-21T04:00:17Z
  https://github.com/continuedev/continue/actions/runs/29800025067/job/88539086045

This PR touches 5 files, none of them under extensions/intellij:

core/tools/implementations/grepSearch.ts          +15/-4
core/tools/implementations/grepSearch.vitest.ts   +86/-0
core/util/grepSearch.ts                           +20/-2
core/util/grepSearch.vitest.ts                    +54/-0
extensions/vscode/src/VsCodeIde.ts                 +7/-2

So nothing in this branch can turn it green. Flagging it rather than pushing an empty commit to re-run, since a re-run against the same base should fail the same way.

The vitest suites added here cover the change itself and are green. Happy to rebase onto a main where that job is passing if that is the preferred way to get a clean run.