[BUG] @ file autocomplete ignores additional working directories (--add-dir / permissions.additionalDirectories)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Files that live in an additional working directory never show up in @ file-mention autocomplete. Only files under the current working directory are ever suggested.

This affects all three ways of registering an extra directory:

• claude --add-dir <path>
• permissions.additionalDirectories in settings.json
• the /add-dir slash command

The directories themselves are registered correctly — Read/Edit/Glob work on them with no permission prompt, and /add-dir lists them. It is only the @ picker that does not see them.

Re-filing: this is the repro for #89726, which was auto-closed as needs-repro.

What Should Happen?

@ autocomplete should search every registered working directory, not just cwd — otherwise the only way to reference a file outside cwd is to type its full path by hand, which defeats the picker.

Steps to Reproduce

mkdir -p /tmp/repro/main-project /tmp/repro/extra-dir
echo "in cwd"            > /tmp/repro/main-project/aaa-in-cwd.txt
echo "in additional dir" > /tmp/repro/extra-dir/zzz-only-in-extra-dir.txt

cd /tmp/repro/main-project
claude --debug-file /tmp/repro/debug.log --add-dir ../extra-dir

Then, in the prompt (wait a beat after each so the index finishes building):

1. Type @aaa -> aaa-in-cwd.txt is suggested. Control case: the picker works.
2. Type @zzz -> no suggestions at all, although ../extra-dir/zzz-only-in-extra-dir.txt is inside a registered working directory.
3. Type a bare @ -> only cwd entries are listed; nothing from extra-dir.

No path form gets around it either: a relative or absolute prefix (@../extra-dir/zzz) can't match, because the index only ever holds cwd-relative paths of cwd files - see the log and the breakdown below.

The extra-dir must not be a subdirectory of cwd — that is the whole point of the additional directory.

Same result when the directory is configured in settings.json instead:

{
  "permissions": {
    "additionalDirectories": ["/tmp/repro/extra-dir"]
  }
}

Error Messages/Logs

Run with --debug-file, the log shows the extra directory being registered, and then the file index being built from cwd alone:

# the additional directory IS registered
14:02:43.800Z [DEBUG] Applying permission update: Adding 1 directory with destination 'cliArg':
                      ["<repro>\extra-dir"]

# ...but the file index only ever looks at cwd's git repo, which holds 1 file
14:03:19.540Z [DEBUG] [FileIndex] getProjectFiles called, respectGitignore=true
14:03:19.540Z [DEBUG] [FileIndex] getFilesUsingGit called
14:03:19.607Z [DEBUG] [FileIndex] git ls-files: 1 tracked files in 67ms
14:03:19.613Z [DEBUG] [FileIndex] using git ls-files result (1 files)
14:03:19.614Z [DEBUG] [FileIndex] skipped index rebuild - tracked paths unchanged
14:03:19.659Z [DEBUG] [FileIndex] background untracked fetch: 0 files

# @zzz -> nothing, because zzz-only-in-extra-dir.txt was never indexed
14:03:19.743Z [DEBUG] [FileIndex] generateFileSuggestions: 0 results in 0ms (full index)
14:03:19.941Z [DEBUG] [FileIndex] generateFileSuggestions: 0 results in 1ms (full index)

1 tracked files is the whole bug in one line: two files exist across the registered working directories, but only the one under cwd reaches the index. The log carries no query text, so the count lines above are matched to keystrokes by timing.

Additional Information

Where it goes wrong — with --debug on, the suggestion index is visibly built from cwd alone:

• Empty query path does a plain readdir of cwd ([FileSuggestions] readdir failed for cwd is the error tag on that branch), so a bare @ can only ever list cwd entries.
• Non-empty query path searches a FileIndex whose roots come from:
• [FileIndex] getFilesUsingGit called → git ls-files --recurse-submodules run in the git root of cwd; returns null ([FileIndex] not a git repo) when cwd is not a repo, and
• the ripgrep fallback → rg --files --follow --hidden … with cwd as its only search root, results relativized to cwd.

Neither source is ever given the registered additional working directories, so no query — bare, basename, or relative path — can match a file outside cwd.

Suggested fix: feed the additional working directories into the same index build as extra roots (one git ls-files / rg --files per root), and label the suggestions with their root so identically-named files stay distinguishable.

My real-world setup — 6 additional directories, sibling repos that are deliberately not subdirectories of the main checkout:

{
  "permissions": {
    "additionalDirectories": [
      "D:/work/shared-claude-config",
      "D:/work/style-lib",
      "D:/work/common-lib",
      "D:/work/k8s-manifests",
      "D:/work/dev-notes",
      "D:/work/analyzers"
    ]
  }
}

None of these are reachable through @, so every cross-repo file reference has to be typed out in full.

Claude Model

Opus

Is this a regression?

No, this never worked

Claude Code Version

2.1.272 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal