[FEATURE] Improve @ file search command for large repos

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The @ file search command in Claude Code becomes noticeably slow in large monorepos, taking several seconds to populate results compared to terminal-based tools like fzf which provide near-instant results. This creates friction in developer workflow when frequently referencing files during conversations with Claude. The delay accumulates over time, especially when exploring unfamiliar codebases, referencing multiple related files in sequence, or iterating on code across different modules. While .claudeignore helps, it requires manual configuration and doesn't match the performance of optimized fuzzy finders in large repositories.

Proposed Solution

Add a configuration option to use fzf (or similar high-performance fuzzy finder) for the @ file search command when available. The implementation would:

1. Check if fzf is installed on the system
2. Use fzf for file search when available, falling back to the current implementation if not
3. Respect both .gitignore and .claudeignore when generating the file list
4. Consider using ripgrep (rg) for initial file list generation, as fzf + ripgrep is a common high-performance

combination

The user experience would be: developers who already have fzf installed (commonly bound to ctrl+t in terminals) would automatically get the same fast search performance in Claude Code, with no additional configuration required beyond an optional setting to enable it.

Alternative Solutions

I open up another terminal window, use fzf to find the file, copy it, then paste it into claude code

Priority

Medium - Would be very helpful

Feature Category

Performance and speed

Use Case Example

Example scenario:

1. I'm working in a large monorepo
2. I need to reference a specific API file to ask Claude about its implementation
3. I type @ to search for the file
4. Current behavior: Search takes 3-5 seconds to populate results per character typed, breaking my flow of thought
5. Desired behavior: Search returns results in <100ms, similar to using ctrl+t (fzf) in my terminal
6. Over the course of a conversation, I might reference 10-20 files, so the time savings would be significant (30-50

seconds saved per character per conversation)

1. This would also reduce cognitive friction - the current delay causes me to lose my train of thought or forget what I was searching for

Additional Context

_No response_