Persistent search is the reason to choose FFF
FFF keeps an indexed view of a repository inside a long-running process. File names and paths can be matched fuzzily, content can be searched as plain text, regex, or fuzzy text, and recently or frequently opened files rise in ranking. The watcher updates the index as the tree changes. Git annotations identify modified, staged, and untracked files. That combination is aimed at editors and agents that issue many related searches, where repeatedly starting independent shell commands loses ranking and warm state.
The project now spans several products. The MCP server exposes file find, grep, and multi-pattern grep to Claude Code, Codex, Cursor, Cline, and other clients. A Pi extension can add tools, replace built-in search, or also replace editor autocomplete. The Neovim plugin supplies interactive pickers and programmatic APIs. Native and language bindings target Rust, C, Python, Node, and Bun. Release 0.10.5 publishes platform binaries, wheels, an sdist, a C FFI library, and the Neovim module.
MCP can reduce round trips, but it adds local state
The MCP tools return paginated path and content results with file metadata, match locations, and optional context. Smart-case search can fall back to fuzzy matching when exact search returns nothing. Definition-like lines are classified before they reach the model, and weak fuzzy matches can be suppressed before they fill agent context. For a coding agent, those decisions may save a separate file discovery call followed by several reads. They also make FFF's ranking policy part of what the agent sees.
Installation is offered through a shell command, PowerShell, Homebrew, or downloaded release artifacts. The README sensibly links the scripts for inspection. After installation, each MCP client still needs an absolute binary path and a restart or new session. FFF writes frecency and history databases plus logs. Issue 820 reports that v0.10.5 places MCP trace logs directly in the root cache directory unless --log-file is set, so managed developer machines should choose explicit XDG-aligned storage before broad rollout.
What happened when we ran it
Our fresh Debian container checked commit 28fce41 through its npm-facing root. Installation completed in 6 seconds, added 0 packages, and left 13 MB on disk. Npm audit reported 0 known vulnerabilities. The checkout contained 372 files, about 69,014 lines of source, and occupied 9 MB. We found 10 CI workflow files, no Dockerfile, and a tests directory.
The root exposed no npm build script or target, so our harness skipped building. It also exposed no npm test script or target, so tests were skipped. Those results do not say that the Rust and native code lacks tests; they say this ecosystem probe did not execute them. It did not compile the MCP server, load a native Node module, start a watcher, or search a repository. Before adopting FFF, run the project's platform-specific checks and benchmark your actual tree, especially if filenames or paths are unusual.
Ignored files remain outside the main index
FFF honors repository ignore behavior during its initial scan. Issue 714 explains the consequence for agent workflows: supplying a concrete path under node_modules or another ignored directory still returns no result because the path only narrows the existing index. The proposal suggests a scoped auxiliary index for an explicitly named path. Until that behavior ships and is verified, agents need a fallback such as direct read, ripgrep with adjusted ignore flags, or a second tool for dependencies and generated outputs.
This limitation can be a feature when the goal is concise source search. Ignored build artifacts and dependencies are often noise, and indexing less content saves memory. The problem appears when an agent is debugging a package's installed manifest or generated file and confidently reports absence. Any MCP prompt that tells an agent to use FFF for every search should preserve an exception for explicit ignored paths and invalid roots. Search policy needs a fallback, not an exclusive mandate.
Platform-specific crashes deserve a release check
Issue 799 reports a fatal background-thread panic on Linux when a path contains invalid UTF-8 bytes. The report ties it to lossy decoding and a byte offset that no longer lands on a character boundary in the released Node artifact. Pull requests 805 and 809 propose fixes, but buyers should confirm which change merged and which tagged release contains it. A native indexer crashing on one filename can interrupt every subsequent agent search in that process.
Android has a different report. Issue 786 describes a reproducible segmentation fault under Termux when a directory contains more than 2 child directories. The report identifies the filesystem walk as the crash site. These issues do not make Linux or Android universally unusable, but they show why release binaries need a corpus test on each supported platform. Include non-UTF-8 names, symlinks, ignored trees, rapid renames, and large directory fan-out.
August activity is fast, and upgrades need care
GitHub recorded 10,149 stars, 75 combined open issues and pull requests, and a push on August 25, 2026. Release v0.10.5 arrived on August 16 with artifacts for its many frontends and fixes around CI, LMDB readers, and Pi database creation. Subsequent issues and pull requests address package loading, watcher sharing, cache paths, and filename handling. The project is active, but its broad surface means one version number covers several runtimes and packaging systems.
FFF earns a trial where search is an interactive loop rather than a single command. Its index, frecency, Git awareness, and agent-focused result shaping solve a real integration problem that ripgrep alone does not. Our 6-second npm check is intentionally weak evidence because it installed no packages and ran no tests. Pin a release, verify its native artifact and storage paths, retain a stateless fallback, and compare complete task behavior instead of trusting a headline search benchmark.