[BUG] @ file picker does not refresh — newly created files invisible until session restart

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?

The @ file picker has an inconsistent behavior for files created after Claude Code is launched:

• The unfiltered list (typing just @ and looking at the dropdown) does include the newly created file. So a filesystem scan / watcher is clearly picking it up.
• The prefix completion (typing @<prefix> and expecting the dropdown to filter to matching files) does not match the new file. It silently behaves as if the file did not exist.

So the dropdown content and the prefix-matching index appear to be out of sync — the picker knows about the file when listing everything, but its prefix-matching layer doesn't.

What Should Happen?

Prefix completion should match all files currently in the working directory, including those created during the session — i.e., the same set of files that already appears in the unfiltered @ dropdown.

Steps to Reproduce

Tested in a non-git directory (no .git/, no .gitignore):

1. mkdir /tmp/picker-refresh-test && cd /tmp/picker-refresh-test
2. echo "a" > existing_one.txt && echo "b" > existing_two.txt
3. claude
4. In the prompt, type @ → dropdown lists existing_one.txt, existing_two.txt ✅
5. Type @exist → dropdown filters correctly to both ✅
6. From a separate shell, while claude is still running:

echo "new" > /tmp/picker-refresh-test/brand_new.txt

1. Back in claude, type @ → dropdown lists all three files including brand_new.txt ✅
2. Type @brand → no suggestion ❌ (despite the file being visible in the unfiltered list one keystroke earlier)
3. /exit and relaunch claude
4. Type @brand → brand_new.txt is now suggested ✅

Claude Code Version

2.1.119

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

GNOME Terminal (bash)

Is this a regression?

I don't know

Additional Information

Related but distinct from #47523 / #48968 / #40082 / #26464, which are about files already present at session start not being indexed at all because the picker uses git ls-files as its only source. The bug here is different: in a non-git directory the filesystem scan does pick up new files for the unfiltered list, but the prefix-matching index is stale and doesn't include them until the session is restarted. Likely the same root cause class (cached file index without invalidation) but a different symptom.

I have not tested whether this also reproduces inside a git init'd repo — that case may overlap with the existing untracked-file bugs above and is harder to disentangle.