search_files can substitute the wrong line when matched text contains :number:

[quifox]

What happened?

search_files can return the wrong source text when a matched line itself contains another :<number>: sequence.

For example, if line 1 is:

src/example.ts:42: build failed

the native grep tool correctly returns:

many.log:1: src/example.ts:42: build failed

but the Step-facing search_files result can become:

many.log:1: src/example.ts:42: UNRELATED_LINE_42

The adapter reparses rendered grep output with a greedy path:line:text regex, mistakes the later :42: for the real line number, then reloads line 42 from the file. Timestamp-shaped text such as 12:34: reproduces the same problem; if the false line number is past EOF, the visible result can become (no matches) while the details still report one match.

I reproduced this on clean main @ f113768 with the built-in tool profile and project-native Vitest, without external extensions.

Steps to reproduce

1. Create a 42-line file where line 1 is src/example.ts:42: build failed and line 42 is UNRELATED_LINE_42.
2. Run search_files for build failed on that file.
3. The native grep result contains the correct line-1 text.
4. The Step-facing result substitutes the contents of line 42.

Expected behavior

search_files should preserve the native match path, line number, and matched text without reinterpreting delimiter-like text inside the match.

Version

main @ f113768 / @step-harness/coding-agent 0.84.4

[xuxujo97-coder]

This comment was generated by AI during triage.

Verification (against current main)

• The parse layer is packages/coding-agent/src/core/tools/grep.ts:296-310 (parseGrepLine, regex ^([^\0]+?):(\d+):(.*)$); its own comment already flags :<digits>:-shaped content as the mis-parse class. Your repro (matched text containing src/example.ts:42: yielding an unrelated line) is consistent with a mis-parse/reload at this boundary; the exact step-facing search_files step that reloads the line is for the maintainers to pin down.

The NUL-separated form mentioned in that comment would remove the ambiguity at the source.