Which fff frontend?
MCP server (fff-mcp)
has logs
Not applicable: this is deterministic incorrect output without a server error.
Description
Summary
multi_grep does not apply standalone positive directory and exact-file constraints. It can therefore return matches outside the requested scope.
Reproduced on fff-mcp 0.10.1; current main contains the same code path. I found no existing issue covering this behavior.
Sanitized reproduction
Use any indexed repository containing:
scope-a/one.txt alpha
scope-a/two.txt beta
scope-b/three.txt alpha
Run:
{
"patterns": ["alpha"],
"constraints": "scope-a/"
}Expected: only scope-a/one.txt.
Actual: matches from both scopes.
The same scope leak occurs with an exact-file constraint such as scope-a/one.txt. Positive glob and negative constraints are applied correctly. Ordinary grep with the equivalent inline query (scope-a/ alpha) is also scoped correctly.
Root cause
In crates/fff-mcp/src/server.rs, multi_grep_inner parses the standalone constraints string with ordinary AiGrepConfig query semantics, then passes only parsed_constraints.constraints to the picker. A lone directory or exact-file token is retained as grep text rather than classified as a constraint, leaving the constraint slice empty.
Standalone constraint fields need constraint-specific parser configuration while ordinary grep queries retain their existing single-token behavior.
Impact
This is a silent scope violation: callers can believe a directory or exact-file restriction was enforced when it was not.
Suggested regression tests
- Standalone positive directory constraint
- Standalone positive exact-file constraint
- Positive glob control
- Negative constraint control
- Ordinary lone path query remains grep text
Which fff frontend?
MCP server (
fff-mcp)has logs
Not applicable: this is deterministic incorrect output without a server error.
Description
Summary
multi_grepdoes not apply standalone positive directory and exact-file constraints. It can therefore return matches outside the requested scope.Reproduced on
fff-mcp 0.10.1; currentmaincontains the same code path. I found no existing issue covering this behavior.Sanitized reproduction
Use any indexed repository containing:
Run:
{ "patterns": ["alpha"], "constraints": "scope-a/" }Expected: only
scope-a/one.txt.Actual: matches from both scopes.
The same scope leak occurs with an exact-file constraint such as
scope-a/one.txt. Positive glob and negative constraints are applied correctly. Ordinarygrepwith the equivalent inline query (scope-a/ alpha) is also scoped correctly.Root cause
In
crates/fff-mcp/src/server.rs,multi_grep_innerparses the standaloneconstraintsstring with ordinaryAiGrepConfigquery semantics, then passes onlyparsed_constraints.constraintsto the picker. A lone directory or exact-file token is retained as grep text rather than classified as a constraint, leaving the constraint slice empty.Standalone constraint fields need constraint-specific parser configuration while ordinary grep queries retain their existing single-token behavior.
Impact
This is a silent scope violation: callers can believe a directory or exact-file restriction was enforced when it was not.
Suggested regression tests