dmtrKovalenko / dmtrKovalenko/fff
[Suggestion]: honor `roots/list_changed` notifications
- Dominant language
- Rust
- Stars
- 10.7k
- Forks
- 446
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 39
Description
### Which fff frontend(s)?
MCP server (fff-mcp)
### What problem are you trying to solve?
Additional workspace roots are never indexed
`fff-mcp` ignores `notifications/roots/list_changed` events, meaning workspace roots added after startup, such as via Claude Code's `/add-dir` are never indexed or searchable.
### The handshake works but the handler is missing
Logs show the client successfully negotiates the `roots` capability and `fff-mcp` receives the `RootsListChangedNotification` event. However, the server never fires a follow-up `roots/list` request to fetch the updated paths, leaving the background indexing threads running strictly on the single directory provided at startup.
### Startup is restricted to a single path
You cannot work around this by passing multiple directories at launch because the CLI only accepts a single `[PATH]` positional argument. Passing a second directory path throws an error because the parser interprets it as the `NO_CONTENT_INDEXING` flag.
I understand this would only work for clients that implement `roots` like Claude Code (e.g. Codex's MCP client does not, per the [MCP client capability matrix](https://github.com/apify/mcp-client-capabilities)).
### Proposed solution
### Suggested Fix
1. **Fetch the updated root list:** On receiving `notifications/roots/list_changed`, call the client's `roots/list` method.
2. **Diff and index:** Compare the returned paths against the currently indexed directories, then spawn the standard background scanning and content-indexing threads for any newly added paths.
Using `/add-dir` in CC should allow the agent to use fff to fetch files in the new directory rather than falling back to grep.
Related to #608
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in the fff-mcp MCP server by tracing handling for RootsListChangedNotification and the existing startup indexing setup. Compare the updated roots with indexed directories, then verify that newly added roots are scanned and searchable without restarting the server.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, search
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100