01Record Cursor version and index status
Capture the installed version, account state, workspace path, and current indexing message.
What the result tells you: A version-specific or service-side issue should not be treated as project corruption.
Appears when: Codebase indexing stuck
Indexing can stall because the workspace is too broad, dominated by generated or binary files, unavailable through filesystem permissions, blocked by network or account state, or held by stale local index data. Preserve the project, narrow the workspace, inspect status, and rebuild the index only after excluding noise.
# Back up workspace settingsRecord exclusions and project-specific configuration before resetting anything.# Exclude generated and irrelevant pathsKeep source, schemas, and important documentation; remove dependencies, outputs, caches, logs, and large artifacts from scope.# Restart with a clean, reachable workspaceResolve filesystem or network access and reopen the intended repository root.# Rebuild once and verify retrievalAfter the workspace is clean, rebuild the index and test known symbols and recently changed files.Preserve the current working revision, change one proven boundary, and verify the published path in a clean session.
Capture the installed version, account state, workspace path, and current indexing message.
What the result tells you: A version-specific or service-side issue should not be treated as project corruption.
Identify generated builds, dependencies, caches, logs, large assets, and nested repositories.
What the result tells you: Indexing unnecessary files increases time and can hide the files that matter.
Confirm Cursor can read the relevant directories and the intended repository is opened at the correct root.
What the result tells you: Permission-denied or remote-filesystem issues prevent a complete index.
Open a clean subset or small repository under the same account and network.
What the result tells you: If a small workspace indexes, project scope or files are more likely than the client installation.
| Likely cause | What proves it | First safe action |
|---|---|---|
| Workspace includes too much generated content | A version-specific or service-side issue should not be treated as project corruption. | Back up workspace settings |
| Filesystem access is incomplete | Indexing unnecessary files increases time and can hide the files that matter. | Exclude generated and irrelevant paths |
| Stale local index state | Permission-denied or remote-filesystem issues prevent a complete index. | Restart with a clean, reachable workspace |
| Client, account, or network issue | If a small workspace indexes, project scope or files are more likely than the client installation. | Rebuild once and verify retrieval |
Indexing can stall because the workspace is too broad, dominated by generated or binary files, unavailable through filesystem permissions, blocked by network or account state, or held by stale local index data. Preserve the project, narrow the workspace, inspect status, and rebuild the index only after excluding noise.
Dependencies, build output, caches, and binaries overwhelm useful indexing work.
The app cannot read part of the repository or a remote mount behaves inconsistently.
The index no longer reflects the current workspace or was interrupted.
Freeze generated changes, restore the last known working version, reproduce one request, collect the browser and platform logs, and change one layer at a time.
Usually no. Excluding generated and dependency directories keeps the index focused on code your team owns.
Only if the client installation is the cause. First test a small workspace and inspect permissions, scope, version, and status.
After correcting exclusions, workspace root, access, or a confirmed stale state. Repeated resets without changing the cause waste time.
Free decision aid
Get a senior view of the constraint, the evidence you have, and the next decision that removes the most risk.
No email required for this decision aid. Dismiss once and this popup stays closed for the session.