Context
Dogfood search --count-by exposed confusing limit behavior.
Evidence
search "catch (Exception" --count-by file --limit 30 returned more grouped rows than expected.--max-json-bytes is only accepted for NDJSON search output, leaving grouped/count output without an equivalent guard.
Additional dogfood evidence
search --recipe risky-code --format count --exclude-tests --limit 120 produced a single very large JSON line; --format count --summary-only --max-json-bytes 6000 was usable.--max-json-bytes is not accepted with --format compact; users have to know which output families support byte caps.- Large grouped outputs also appeared in assertion, exception, and token searches where
--limit did not feel like a strict final-output row budget.
- Follow-up searches for broad tokens such as
CDIDX_MCP and sampling exceeded the surrounding tool context, which points at a need for first-class group/facet/truncation controls on large searches.
symbols --sort line is rejected today; for audit workflows, a stable file-order or line-order sort would make symbol lists easier to compare with outline, excerpt, and manual review.languages --json is useful but broad; filtering by capability gap, graph support, reference support, or current-workspace languages would reduce follow-up query noise.- Search/audit sessions would benefit from output metadata that separates final row count, matched row count, grouped row count, dropped match lines, and byte truncation for every text/JSON output family.
Risk
Large grouped searches can produce unexpectedly large output and make scripted audits harder to bound.
Suggested direction
Clarify --limit semantics for grouped output and add row/byte caps that work for count/group/compact modes. Consider explicit --max-groups, --max-output-rows, line/file-order sorting, capability facets, and machine-readable truncation metadata.
Context
Dogfood
search --count-byexposed confusing limit behavior.Evidence
search "catch (Exception" --count-by file --limit 30returned more grouped rows than expected.--max-json-bytesis only accepted for NDJSON search output, leaving grouped/count output without an equivalent guard.Additional dogfood evidence
search --recipe risky-code --format count --exclude-tests --limit 120produced a single very large JSON line;--format count --summary-only --max-json-bytes 6000was usable.--max-json-bytesis not accepted with--format compact; users have to know which output families support byte caps.--limitdid not feel like a strict final-output row budget.CDIDX_MCPandsamplingexceeded the surrounding tool context, which points at a need for first-class group/facet/truncation controls on large searches.symbols --sort lineis rejected today; for audit workflows, a stable file-order or line-order sort would make symbol lists easier to compare withoutline,excerpt, and manual review.languages --jsonis useful but broad; filtering by capability gap, graph support, reference support, or current-workspace languages would reduce follow-up query noise.Risk
Large grouped searches can produce unexpectedly large output and make scripted audits harder to bound.
Suggested direction
Clarify
--limitsemantics for grouped output and add row/byte caps that work for count/group/compact modes. Consider explicit--max-groups,--max-output-rows, line/file-order sorting, capability facets, and machine-readable truncation metadata.