find_files drops bracket-prefixed paths in narrowed searches

[quifox]

What happened?

find_files can silently drop valid matches when the returned relative path starts with [ or WARNING:.

A common case is a narrowed search inside a Next.js routes directory. With routes/[id]/page.tsx present, find_files with path: "routes" returns (no matches), even though the native find backend returns [id]/page.tsx correctly. The same reproduces with [...slug] and [[...slug]].

The Step adapter currently strips every native output line starting with [ or WARNING:, so valid paths are treated as notices.

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 routes/[id]/page.tsx.
2. Run find_files with:

   { "pattern": "*.tsx", "path": "routes" }

3. The native find tool returns [id]/page.tsx.
4. The Step-facing find_files result is (no matches), with matchedFiles: 0 and returnedFiles: 0.

Expected behavior

Valid file paths should not be removed because their relative path happens to start with text used by native notices.

Version

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

[xuxujo97-coder]

This comment was generated by AI during triage.

Verification (against current main)

• Notice handling exists at packages/coding-agent/src/step/tool-profile.ts:193-201 (WARNING: banners are a deliberate protocol for truncation notices). If the find adapter strips every line starting with [ or WARNING: — your repro shows it does — valid bracket-prefixed paths like [id]/page.tsx collide with the notice protocol; the collision class is real for Next.js-style routes.

Maintainers will confirm the stripping site and whether a structured notice channel can replace prefix-matching.