claude-code - 💡(How to fix) Fix [BUG] FileIndex re-indexes large non-git codebase via ripgrep on every turn [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
anthropics/claude-code#45437Fetched 2026-04-09 08:05:27
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Participants
Timeline (top)
labeled ×6renamed ×1

Error Message

Error Messages/Logs

Fix Action

Fix / Workaround

When there is a git repo, Claude reindexes once at the start of the session and then never again. I've been able to confirm this as a workaround by creating a local git repo, and after all of the files are committed, the hitch no longer occurs (confirmed times by looking at debug logs).

Code Example

[FileIndex] getProjectFiles called, respectGitignore=true
  [FileIndex] getFilesUsingGit called
  [FileIndex] not a git repo, returning null
  [FileIndex] git ls-files returned null, falling back to ripgrep
  [FileIndex] ripgrep: 204372 files in 12842ms
  [FileIndex] cache refresh completed in 13049ms
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Working with Claude Code on a large project (200k+ files), but without a git repo (we use P4). I'm seeing multi-second hitches every turn as Claude re-indexes files. On my machine this is currently taking between 7-13 seconds every turn, on a slower machine in the office here it takes 20+ seconds.

When there is a git repo, Claude reindexes once at the start of the session and then never again. I've been able to confirm this as a workaround by creating a local git repo, and after all of the files are committed, the hitch no longer occurs (confirmed times by looking at debug logs).

If I use an .ignore or .rgignore, I can reduce the number of files that ripgrep tests, but the re-indexing is still occurring every turn.

What Should Happen?

For non-git repos there should be some kind of file index cache for the and not re-scan files every turn.

Error Messages/Logs

[FileIndex] getProjectFiles called, respectGitignore=true
  [FileIndex] getFilesUsingGit called
  [FileIndex] not a git repo, returning null
  [FileIndex] git ls-files returned null, falling back to ripgrep
  [FileIndex] ripgrep: 204372 files in 12842ms
  [FileIndex] cache refresh completed in 13049ms

Steps to Reproduce

  1. In a project with hundreds of thousands of files (ours has ~230k), open Claude Code. Do not create a git repo at that location (or above it in the file path)
  2. Note that Claude Code hitches on startup, and every turn afterwards

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.96

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

[FileIndex] getProjectFiles called, respectGitignore=true [FileIndex] getFilesUsingGit called [FileIndex] not a git repo, returning null [FileIndex] git ls-files returned null, falling back to ripgrep [FileIndex] ripgrep: 211764 files in 6758ms [FileIndex] cache refresh completed in 6992ms

[FileIndex] getProjectFiles called, respectGitignore=true [FileIndex] not a git repo, returning null [FileIndex] git ls-files returned null, falling back to ripgrep [FileIndex] ripgrep: 203599 files in 6654ms [FileIndex] cache refresh completed in 6890ms

[FileIndex] getProjectFiles called, respectGitignore=true [FileIndex] not a git repo, returning null [FileIndex] git ls-files returned null, falling back to ripgrep [FileIndex] ripgrep: 202984 files in 6619ms [FileIndex] cache refresh completed in 6853ms

[FileIndex] getProjectFiles called, respectGitignore=true [FileIndex] not a git repo, returning null [FileIndex] git ls-files returned null, falling back to ripgrep [FileIndex] ripgrep: 208870 files in 6762ms [FileIndex] cache refresh completed in 6987ms

[FileIndex] getProjectFiles called, respectGitignore=true [FileIndex] not a git repo, returning null [FileIndex] git ls-files returned null, falling back to ripgrep [FileIndex] ripgrep: 201247 files in 7306ms [FileIndex] cache refresh completed in 7537ms

extent analysis

TL;DR

Implementing a file index cache for non-git repositories in Claude Code could resolve the multi-second hitches caused by re-indexing files every turn.

Guidance

  • The issue is likely caused by the absence of a git repository, which triggers Claude Code to re-index files using ripgrep every turn, resulting in significant performance hitches.
  • To verify the cause, compare the performance of Claude Code with and without a git repository, as the user has already done.
  • A potential workaround is to create a local git repository, commit all files, and then use Claude Code, as this has been shown to prevent the re-indexing issue.
  • Another possible mitigation is to use .ignore or .rgignore files to reduce the number of files that ripgrep tests, although this may not completely eliminate the re-indexing issue.

Example

No specific code example is provided, as the issue is related to the configuration and behavior of Claude Code rather than a specific code snippet.

Notes

The exact implementation of a file index cache for non-git repositories in Claude Code is not specified, and it may require modifications to the Claude Code software itself.

Recommendation

Apply a workaround by creating a local git repository and committing all files, as this has been shown to prevent the re-indexing issue, until a more permanent solution, such as implementing a file index cache for non-git repositories, is available.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING