[BUG] @ file completion is completely empty when cwd is a gitignored subdirectory of a git repo

Environment

• Claude Code v2.1.202 (native arm64 binary), macOS, terminal TUI

Summary

If the current working directory is inside a gitignored subdirectory of a git repository, the @ mention file index is completely empty — not even files sitting directly in the cwd are offered. It looks like the "project" is resolved to the nearest enclosing git repo, and file enumeration respects that repo's .gitignore, which excludes everything under the cwd.

Minimal repro

mkdir -p proj/sessions/s1 && cd proj
git init && echo 'sessions/' > .gitignore
git add .gitignore && git commit -m init
echo hello > sessions/s1/notes.md
cd sessions/s1 && claude
# type: @notes   → no file suggestions at all (only agents/skills/MCP resources)

The same directory layout outside a git repo → @notes completes fine.

Related observation: dir-symlink traversal differs between git and non-git cwd

• non-git cwd: the @ index follows a symlinked directory — even into a large external git repo (~17k files) — with correct .gitignore pruning inside it 👍
• git cwd (same directory after git init): the same symlinked directory is not traversed at all

This asymmetry makes behavior hard to predict for workspace-launcher setups (cwd = small session dir, real code reachable via symlinks or --add-dir).

Expected

• Files in and under the cwd should be completable via @ even when the cwd is gitignored by an outer repo — the user deliberately launched there, so an entirely empty index is never what they want.
• Ideally: consistent symlink traversal between git/non-git cwd, and --add-dir roots included in the index (#7412).

Use case

Internal multi-repo orchestration: claude is launched in a per-session workspace directory (kept out of version control via gitignore), with the product repos attached via --add-dir. In this configuration @ completion offers nothing at all, so every file reference has to be typed as a full absolute path from memory 🙂

All of the above was verified with scripted TUI sessions (expect + terminal-emulator screen capture), each case reproduced multiple times.