Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix Selection list for @ file references does not update until after the current turn is completed [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#24981•Fetched 2026-04-09 08:16:37
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
shaunduncanshaunduncan
Participants
shaunduncanshaunduncan
Timeline (top)
labeled ×2cross-referenced ×1

Fix Action

Fix / Workaround

I would describe this as a minor usability inconvenience - there is an acceptable workaround.

PR fix notes

PR #24840: fix: detect newly created files in @ recommendations with core optimizations

Description (problem / solution / changelog)

Summary

This PR enables the Gemini CLI to dynamically detect newly created files in the @ mention menu without requiring a CLI restart. It resolves a critical friction point where files generated by the agent were not immediately available for referencing.

Details

  • CLI Refresh Logic: Modified the useAtCompletion hook to re-initialize searchers every time the @ menu is activated.
  • Core Concurrency Protection: Introduced an InitializationState enum and initPromise in RecursiveFileSearch. This ensures that concurrent initialization calls (e.g., from fast UI re-renders) correctly await the same ongoing process instead of spawning redundant disk crawls.
  • Performance Calibration:
    • Lowered the crawler cache TTL to 5 seconds for the @ menu. This ensures near-instant discovery of new files while protecting against "hammering" the disk in massive repositories.
    • Implemented a referential equality check on the file list instance to skip expensive FZF re-indexing if the filesystem has not changed since the last crawl.
  • Immediate Caching: Updated the CLI hook to cache searcher instances immediately upon creation (during the creation loop), preventing redundant searcher instantiation during in-flight initializations.

Related Issues

Fixes #24729, #24981

Pre-Merge Checklist

  • Updated relevant documentation and README (if needed)
  • Added/updated tests (if needed)
  • Noted breaking changes (if any)
  • Validated on required platforms/methods:
    • Linux
      • npm run
      • npx

Changed files

  • packages/cli/src/ui/hooks/useAtCompletion.test.ts (modified, +47/-0)
  • packages/cli/src/ui/hooks/useAtCompletion.ts (modified, +25/-19)
  • packages/core/src/utils/filesearch/fileSearch.test.ts (modified, +75/-0)
  • packages/core/src/utils/filesearch/fileSearch.ts (modified, +69/-28)
RAW_BUFFERClick to expand / collapse

What happened?

If I add or create a new file in the current working directory, it does not appear in the @ selection list until the next user turn (i.e. I am entering text in a new input prompt)

What did you expect to happen?

After adding a new file (in this case a task.md file), that @ would show that file in the selection list.

Client information

  • CLI Version: 0.37.0
  • Git Commit: 352bbe149
  • Session ID: fdb9e400-25fc-4f4e-ae4c-2cf875da217d
  • Operating System: linux v22.22.0
  • Sandbox Environment: no sandbox
  • Model Version: auto-gemini-3
  • Auth Type: oauth-personal
  • Memory Usage: 791.0 MB
  • Terminal Name: tmux 3.5a
  • Terminal Background: #000000
  • Kitty Keyboard Protocol: Unsupported

Login information

No response

Anything else we need to know?

I would describe this as a minor usability inconvenience - there is an acceptable workaround.

extent analysis

TL;DR

The issue can be mitigated by entering text in a new input prompt after adding a new file, which will update the @ selection list.

Guidance

  • The likely cause is a delay in updating the @ selection list after creating a new file.
  • To verify, try adding a new file and then immediately enter text in a new input prompt to see if the file appears in the @ selection list.
  • As a workaround, users can enter text in a new input prompt after adding a new file to update the @ selection list.
  • The issue is described as a minor usability inconvenience, and the workaround is considered acceptable.

Notes

The issue seems to be related to the updating of the @ selection list, and the workaround provides a temporary solution. However, the root cause of the delay in updating the list is not clear.

Recommendation

Apply workaround, as it provides an acceptable temporary solution to the minor usability inconvenience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#ISR setup#authentication setup#request error#file not found#serialization error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

gemini-cli - ✅(Solved) Fix Selection list for @ file references does not update until after the current turn is completed [1 pull requests, 1 participants]