[yolandaycao]

code_search -l was parsing filenames as JSON and reporting zero matches. Parse filename output directly while preserving -l and the existing limits. Non-UTF-8 paths use base64, matching ripgrep's JSON output, so distinct filenames stay distinct.

All 33 existing tests and 14 additional local checks pass. SDK typecheck still has the same 6 existing errors as main.

[codebuff-team]

Good catch — when flags contains -l/--files-with-matches, ripgrep's last-flag-wins semantics mean it emits a plain filename list instead of JSON lines, and the current parser silently drops every match. That's a legitimate defect worth porting.

The execution is where I'd push back. hasFilenameOutput() hand-rolls a chunk of ripgrep's CLI grammar: a hardcoded RIPGREP_VALUE_FLAGS set for long options, plus a second hardcoded string 'efEmjgdtTABCMr' for short options that consume a value. Both lists have to stay perfectly in sync with ripgrep's actual flag set (e.g. is -d really a value-taking short flag in rg? I don't think it exists at all), and any omission means either a glob/value gets misread as a flag toggle, or a real toggle gets swallowed as someone else's value. This is exactly the kind of code that needs dedicated unit tests for combined short options (-lin), split short options with embedded values (-eFOO vs -e FOO), glob-like tokens (-g*.html), and flags after --. The PR only reports that the existing 33 e2e-style tests pass — none of those exercise hasFilenameOutput directly, so its many branches are effectively untested.

Consider a simpler, more robust approach: rather than statically predicting rg's output mode by re-parsing the flag array, sniff the actual first bytes of stdout (JSON lines start with {, -l output doesn't) and switch parsing strategy at runtime. That avoids reimplementing rg's flag precedence rules entirely and is far less likely to drift as ripgrep's flag surface changes.

Also worth double-checking: formatCollectedOutput's filenames-only branch hardcodes Found ${matchesGlobal} matches — confirm this reads sensibly when -l is combined with -c-style overrides mid-flag-list (last-wins logic determines filenamesOnly for the whole run, but is that always what a user combining flags expects?).

Right problem, but I'd want the flag-classification logic replaced or heavily tested before this goes in as-is.

[codebuff-team]

Marking this stale - there has been no activity here for 29 days. It will close in 7 days unless someone comments.

This is backlog upkeep, not a verdict on the pull request. A single comment keeps it open, and anything closed this way can be reopened.