Where is the re-index button now?

`Cursor Settings → Indexing`. Cursor renamed the old "Codebase" settings pane to "Indexing" in early 2026, so guides pointing at `Settings → Codebase` are stale.

How often does Cursor sync the index?

Automatically about every 5 minutes, processing only changed files. That is why a rebase can look stale for a few minutes until the next cycle.

Will my index disappear if I leave a project alone?

Yes. As of June 2026 Cursor deletes an indexed codebase after 6 weeks of inactivity; reopening the project triggers a fresh index.

Does indexing share my code with the cloud?

Embeddings are computed server-side and stored (in Turbopuffer) with obfuscated file paths and line ranges; the raw source is not retained. `Cursor Settings → Privacy` (Privacy Mode) keeps everything local but indexing is slower.

Can I trigger a re-index from the CLI?

Not officially. `Cursor Settings → Indexing → Resync Index` is the supported path.

Does Cursor re-index on branch switch automatically?

Partially. It picks up file deletes and adds on the next sync but can miss large in-place rewrites, and the agent's file-read cache may still serve old-branch content. Reload the window and resync after a big rebase.

Troubleshooting

Cursor Codebase Index Stale After Rebase or Branch Switch

After a rebase or branch switch Cursor cites files and line numbers that no longer exist. The indexer fell behind your git state. Force a re-index and harden the workflow.

Published: May 24, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

You finish a rebase, switch branches, or pull a big merge, then ask Composer “where is the parseConfig helper used?” and Cursor confidently points at src/utils/oldHelpers.ts — a file that no longer exists. Or it cites line numbers from a file that was heavily rewritten, and the diff it proposes lands on line ranges that have shifted. The codebase index is the cache Cursor builds to answer @codebase and semantic-search queries. It auto-syncs roughly every 5 minutes and processes only changed files, so the bulk rewrites that come with a rebase, branch switch, or large merge can take a full sync cycle to land — and on macOS the filesystem-event coalescing can make the indexer see a smaller change set than reality. The index lags your git state, the model gets stale context, and the answers are wrong with full confidence.

Fastest fix: open Cursor Settings → Indexing, click Resync Index (older builds label it Re-index), wait for the status to read up to date, then start a fresh Composer thread. That clears stale chunks for ~70% of cases. The rest of this guide covers diagnosis and the deeper fixes for worktrees, ignore rules, and corrupted workspace storage. Menu path verified June 2026 — Cursor renamed the old Settings → Codebase pane to Settings → Indexing, so older guides pointing at “Codebase” are out of date.

Which bucket are you in

Match your symptom to the likely cause before you start clicking.

Symptom	Most likely cause	Go to
`@codebase` cites a deleted/renamed file	Watcher missed the bulk change; sync not run yet	Step 2, then Step 3
Agent `read_file` / edits return old-branch content	Tool cache stale after `git checkout`	Step 2
New files from the rebase never appear	`.cursorignore` / `.gitignore` excludes them	Step 4
Status shows Paused or Throttled	Indexing paused on battery/high CPU	Step 3
Title-bar path differs from your terminal `pwd`	Wrong worktree open	Step 1, then Step 6
Re-index runs but answers stay wrong	Corrupt workspace storage	Step 7

Common causes

Ordered by hit rate, highest first.

1. The watcher missed a bulk filesystem change

The indexer relies on filesystem events and a periodic sync. A rebase rewrites many files in a tight loop; on macOS especially, fsevents coalesces events and the indexer sees fewer changes than actually happened, then waits for the next ~5-minute sync to reconcile.

How to judge: Cursor Settings → Indexing → check the “Last synced”/status line. If it predates your rebase, the sync has not caught up.

2. The agent or branch switch is serving stale file content

This is the more dangerous variant. After git checkout the editor’s opened files and the agent’s read_file / search_replace tools can keep returning the previous branch’s content, which lets legacy-branch code leak into an edit Cursor then commits. This is a confirmed behavior in the Cursor forum, with reloading the window as the official workaround.

How to judge: Open a file you know changed across the branch swap. If the editor or Composer shows the old text, the working copy and tool cache are stale.

3. Indexing is paused or throttled

If Cursor detected high CPU or low battery it may have paused background indexing, so no resync ran after your rebase.

How to judge: Cursor Settings → Indexing → status. “Paused” or “Throttled” with a battery/CPU note means the resync has not run.

4. `.gitignore` or `.cursorignore` excluded the new files

After a rebase the new tree may put files in directories your ignore rules exclude. The indexer skips them and Composer cannot see them. Cursor honors .gitignore plus two Cursor-specific files: .cursorignore (hard block — the file is hidden from indexing and from @Files references and autocomplete) and .cursorindexingignore (excluded from the index but still reachable via @Files).

How to judge: Inspect .cursorignore, .cursorindexingignore, and .gitignore at the new HEAD. If the new file’s path matches a pattern, that is why it is missing.

5. The embeddings cache holds vectors keyed to old content

Cursor chunks each file, computes embeddings server-side, and stores them (in Turbopuffer) with an obfuscated relative path plus the line range — the raw code is not retained. After a rebase the content hash changes but the path stays, so old vectors are evicted slowly and queries hit stale neighbors.

How to judge: A forced resync (Step 3) fixes it. If results snap into place right afterward, this was the cause.

6. You are on a worktree and Cursor opened the wrong one

If you use git worktree, opening Cursor at the main repo path while editing in the worktree path gives you an index pointing at the main worktree.

How to judge: Check the title-bar path. If it differs from pwd in the terminal you have been using, you are out of sync.

Before you start

Commit or stash any in-flight changes; the resync reads from disk and you do not want partial state cached.
Have a minute or two of CPU budget; a full resync of a large repo is not instant.
Know the size of your codebase (file count and total LOC) so you can set expectations.

Information to collect

Cursor version (Cursor → About Cursor, or Help → About).
Repo size: find . -type f \( -name '*.ts' -o -name '*.js' -o -name '*.py' \) | wc -l.
Cursor Settings → Indexing → status / last-synced line.
git log --oneline -10 to confirm the rebase happened.
Whether you are on a worktree (git worktree list).
.cursorignore, .cursorindexingignore, and .gitignore contents.
Recent entries in ~/.cursor/logs/ matching index or embed.

Step-by-step fix

Step 1: Confirm Cursor knows the right HEAD

Open the integrated terminal in Cursor and run git rev-parse HEAD. Open an external terminal at the same path and run the same. They must match. If they do not, Cursor opened a different path (worktree, symlinked copy) — jump to Step 6.

Step 2: Reload the window

Cmd+Shift+P → “Developer: Reload Window.” This re-scans the working tree and is the official fix for the stale-file and stale-tool-cache problem after a git checkout. For roughly a third of stale-index cases this is enough and the resync catches up within a sync cycle.

Step 3: Force a full resync

Cursor Settings → Indexing → click Resync Index (older builds: Re-index). This drops the existing chunk and embedding cache for the workspace and rebuilds from disk. On a 100k-file repo this can take 5-15 minutes; watch the status line until it reads up to date rather than trusting answers mid-rebuild.

Step 4: Verify your ignore rules

If new directories appeared after the rebase, make sure .cursorignore and .cursorindexingignore do not exclude them. A common gotcha: the pattern dist/ also excludes nested dist/ under any package. Use .cursorindexingignore (not .cursorignore) when you still want to @-reference a file but keep it out of the index.

Step 5: Clear codebase context in Composer

Start a new Composer conversation. Existing threads keep the file references they already gathered; only a new thread does a fresh fetch against the rebuilt index.

Step 6: For worktrees, open the worktree path directly

Quit Cursor. Re-open with cursor /path/to/the/worktree or File → Open Folder. Each worktree should be its own Cursor window with its own index — never share one index across worktrees.

Step 7: If still wrong, clear the workspace storage

As a last resort, quit Cursor and remove the workspace’s storage folder (back it up first if you care about chat history):

macOS: ~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/
Linux: ~/.config/Cursor/User/workspaceStorage/<hash>/
Windows: %APPDATA%\Cursor\User\workspaceStorage\<hash>\

Re-open the project; Cursor builds clean workspace storage and a clean index.

How to confirm it’s fixed

Ask Composer for the path of a file you renamed in the rebase. It must return the new path.
Ask for the line number of a function that moved. It should match what you see in the editor.
Run an @codebase query that should hit a newly added file. The file should appear in the references.
Run a Cmd-K edit on a moved file; the diff should target the right lines.
Cursor Settings → Indexing status should read up to date with a “last synced” time after your rebase.

Long-term prevention

After any rebase or large merge, click Resync Index once. Treat it like a build step.
Avoid switching branches with Cursor open if the diff is huge; quit, switch, relaunch.
Use one Cursor window per worktree; never share an index across them.
Keep .cursorignore lean and explicit; broad patterns silently shrink the index.
Pin Cursor to a version where indexing is known stable for your repo size — newer is not always faster.

Common pitfalls

Trusting @codebase answers right after a rebase without checking. The first sync cycle is almost always stale.
Re-indexing on battery power; it can throttle and look done while still incomplete.
Editing .cursorignore mid-index; the runner may use the old rules until restart.
Assuming “Reload Window” forces a full re-index. It re-scans the working tree but does not rebuild embeddings — use Resync Index for that.
Letting Cursor index a node_modules-equivalent. Always ignore vendored or build directories.

FAQ

Where is the re-index button now? Cursor Settings → Indexing. Cursor renamed the old “Codebase” settings pane to “Indexing” in early 2026, so guides pointing at Settings → Codebase are stale.
How often does Cursor sync the index? Automatically about every 5 minutes, processing only changed files. That is why a rebase can look stale for a few minutes until the next cycle.
Will my index disappear if I leave a project alone? Yes. As of June 2026 Cursor deletes an indexed codebase after 6 weeks of inactivity; reopening the project triggers a fresh index.
Does indexing share my code with the cloud? Embeddings are computed server-side and stored (in Turbopuffer) with obfuscated file paths and line ranges; the raw source is not retained. Cursor Settings → Privacy (Privacy Mode) keeps everything local but indexing is slower.
Can I trigger a re-index from the CLI? Not officially. Cursor Settings → Indexing → Resync Index is the supported path.
Does Cursor re-index on branch switch automatically? Partially. It picks up file deletes and adds on the next sync but can miss large in-place rewrites, and the agent’s file-read cache may still serve old-branch content. Reload the window and resync after a big rebase.

Tags: #Cursor #Indexing #git #Troubleshooting