@ file-mention autocomplete only searches primary cwd, not directories added via --add-dir / additionalDirectories

Status Open

Maintainer reply ✓ Yes — bcherny

Activity 4 comments · opened Jul 8, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

What happened

When multiple working directories are registered — via the --add-dir flag, the /add-dir command, or permissions.additionalDirectories in settings — the @ file-mention autocomplete only searches the primary working directory (the one claude was launched from). Files in the additional directories are not surfaced by the picker, even though tools (Read/Edit/etc.) can access them.

Steps to reproduce

Launch from one project: cd ~/projects/docker/ecommerce && claude --add-dir ~/projects/docker/skyhook
Confirm both show as working directories in the session.
Type @ and start typing the name of a file that exists only in skyhook.

Expected: the picker offers files from all registered working directories.
Actual: the picker only offers files under the primary cwd (ecommerce); files in skyhook never appear.

Environment

Claude Code v2.1.204
macOS (darwin 25.5.0), zsh
Directories registered via both --add-dir and permissions.additionalDirectories

Why it matters

For monorepo-adjacent setups (many sibling project repos under one parent), cross-project file references are a common workflow. --add-dir is the documented way to register additional working directories, but the @ picker not indexing them means you have to type full relative paths by hand instead of using autocomplete.

Request

Either (a) have the @ file-mention autocomplete search across all registered working directories, or (b) document explicitly that the picker is scoped to the primary cwd and clarify the intended way to reference files in additional directories.

View original on GitHub ↗

3 Comments

victorjkhalaf · 3 months ago

Confirmed still reproduces on v2.1.204 (macOS).

Tested by launching claude with explicit --add-dir flags for 12 sibling project directories (verified all 12 register as working directories in the session). Typing @ and searching for a filename that exists only in one of the added directories still returns no results from that directory — the picker only surfaces files under the primary cwd.

So this is not specific to permissions.additionalDirectories; it reproduces with the documented --add-dir flag as well. Tools (Read/Edit) can access the added directories fine — the gap is purely in the @ mention autocomplete's search scope.

wilf-phasecraft · 2 months ago

+1 for this, looks like there are several older closed issues asking for the same thing. I feel like developing across multiple repos simultaneously is quite common, and this would be very useful

bcherny collaborator · 1 month ago

Confirmed — reproduced on 2.1.233 (Linux).

Setup: launched from one project with a sibling registered via --add-dir, verified with /add-dir that the second directory was registered ("already added as a working directory"), then typed @ + a filename that exists only in the added directory.

Files in the primary working directory are suggested as expected.
Files in the additional directory never appear in the picker, whether the directory was added via --add-dir at launch or /add-dir at runtime — even though tools can read them fine.

So this is a real gap: the @ file-mention picker only indexes the launch directory (and its repo root), not the other registered working directories. Not a recent regression — the picker has never covered additional directories. We're tracking making the picker index all registered working directories. In the meantime, typing an absolute path after @ (e.g. @/path/to/other/project/file.ts) works as a manual workaround.

🤖 Generated with Claude Code

Showing cached comments. Read the full discussion on GitHub ↗