fix(mcp): Follow grep separator and prefix semantics in grep_repomix_output output - #1869

Summary

grep_repomix_output's formattedOutput is documented as grep-style output, but two of its formatting rules are not grep -C rules, and the code implementing them fails outright on repository-sized outputs. Fixes #1868.

The gap check compared the wrong pair of blocks.

if (resultLines.length > 0 && start > Math.min(...addedLines) + 1) {

addedLines accumulates every line emitted so far, so Math.min(...addedLines) is the start of the first block, not the end of the previous one. The condition reads "does this block start after the first line?" instead of "are lines missing between these two blocks?", so -- was pushed between blocks that touch or overlap. Tracking lastBlockEnd as a running maximum asks the intended question.

A match could be labelled as context. The prefix came from i === match.lineNumber - 1, evaluated only for the match currently being rendered, and lines already in addedLines were skipped. When an earlier match's context emitted a line that is itself a match, it kept the - prefix. Deciding from the set of matching line numbers makes the mark independent of emission order.

The same expression was also the failure mode on large outputs. It re-spreads every accumulated line per match: quadratic, and past a few hundred thousand entries the argument list exhausts the stack. lastBlockEnd is a scalar comparison, so the loop is linear and has no argument limit to hit.

Measured before / after

Fixture from #1868 (six lines, four matches two apart), called through the stdio MCP server with contextLines: 1. Lines 50–57 are consecutive, so the correct output has no separators; totalMatches reported 4 while only 3 lines were marked.

Before:

50-<file path="src/greetings.js">
51:export const hello = 'hello';
52-const padHello = (s) => s.trim();
--
53:export const helloWorld = 'hello world';
54-export const helloThere = 'hello there';
--
55-const goodbye = 'goodbye';
--
56:export const helloAgain = 'hello again';
57-</file>

After:

50-<file path="src/greetings.js">
51:export const hello = 'hello';
52-const padHello = (s) => s.trim();
53:export const helloWorld = 'hello world';
54:export const helloThere = 'hello there';
55-const goodbye = 'goodbye';
56:export const helloAgain = 'hello again';
57-</file>

formatSearchResults directly, disjoint matches 8 lines apart, context 1/1, one core:

The RangeError is caught by the tool and returned as reason: "SEARCH_ERROR" with the message Error: Maximum call stack size exceeded, so the client gets no result rather than a partial one.

Tests

• Two new formatSearchResults cases: a real gap still separates, and overlapping blocks do not.
• Five existing expectations encoded the previous output (-- between overlapping blocks, '3-line 3' for a matching line, and the multilingual integration case where lines 2 and 3 are matches rendered as context). They are corrected here rather than relaxed — each now asserts the grep -C result for the same input.
• No timing test is added for the stack overflow: the input needed to cross the threshold takes tens of seconds on the old code, so the numbers live in grep_repomix_output: -- separators inside contiguous context blocks, matches printed with the context prefix, and RangeError on large outputs #1868 instead.

Checklist

• Run npm run test
• Run npm run lint

Also npx tsc --noEmit clean, npm run build clean, and the change was reverted source-side only to confirm 7 tests fail without it.