What do you think about Cursor removing the codebase indexing settings?

Discussions
, ,
1

I noticed that recent Cursor versions have removed the previous codebase indexing page, including indexing status, included files, and manual reindex controls.

From the recent product direction, Cursor also seems to be relying more on agentic search, grep, file exploration, and subagents for repository understanding.

I’m curious how other users feel about this change, especially those working with large, long-running, or poorly documented codebases.

Personally, I have always considered codebase indexing to be one of Cursor’s most important technical advantages. It was not merely a convenience feature to me. I saw it as part of Cursor’s moat, and as a foundation that could be continuously improved over time:

  • better repository-level retrieval;
  • stronger understanding of cross-file relationships;
  • lower repeated exploration cost;
  • more stable context across tasks;
  • better performance on repositories with inconsistent naming or weak documentation.

Agentic search may turn out to be the better direction, and the Cursor team may already have validated it extensively in real engineering workloads. But I do not think persistent indexing and agentic exploration are necessarily substitutes. They may be strongest when used together.

I’m interested in hearing actual experiences from other users:

  • Have you noticed any change in repository understanding in recent versions?
  • Does the current agentic search approach perform better or worse for your projects?
  • Do agents spend more time rediscovering the repository?
  • Is indexing still happening internally, with only the user-facing controls removed?
  • Has anyone tested this across multiple recent versions?

My concern is not simply that one settings page disappeared. It is whether Cursor is moving away from a capability that helped distinguish it from general-purpose coding agents.

I would like to understand how other users see this change before drawing a stronger conclusion.

5

@Alphayellowcat thanks for the question, you are correct, we recently made some changes to how agents search the codebase. Over the last months, models have gotten really good at using grep / indexed search, so the older dedicated semantic search path was rapidly no longer helping in a meaningful way.

Agents now lean on our “Instant Grep” tool (and normal file reads), which is what you are seeing in the tool list. For almost all workflows this should feel the same or better, if something specific got worse for you after this change, reply with a request id and repo shape and we will dig in.

Also since search now runs directly against the files on your machine, Cursor no longer needs to build a semantic index of your codebase which means we’re no longer computing embeddings of your code or storing them on our servers for search.

On some older versions of Cursor, the indexing UI may still show progress, that does not mean a separate semantic search tool is available to the agent.

7

Does it respect cursor ignore?

8

@maximep So, the absence of codebase Indexing in the recent update is expected? Also, is the Instant Grep limited to the files set by cursorignore? Is the 250,000-file limit applicable in the newer update?

image
image700×687 23.4 KB

9

+1 on this. Can you confirm:

  1. How to control which file/folder the Agent can grep now? Does it still respect .cursorignore and .gitignore?
  2. In the “Indexing & Docs” setting page, in the past I can click on “View included files” to open the “embeddable_files.txt” which lists out all the files that will be indexed so Cursor can find it quickly, and I also treat it as a way to check if my current .gitignore and .cursorignore rules are good (no important files are being missed/no gabbage files are being indexed). Now the indexing mechanism is gone, how to check this?
  3. Concept search without a name gets worse. “Where do we handle DTC ship updates?” with no ShippedProcessor in mind was the one place embeddings helped. Grep needs a seed token. Agents can invent seeds, but that costs turns and fails more on inconsistent naming (Adobe Commerce/Shopify is full of that).
10

Hey all! Let me try to answer your questions.

Yes. Semantic/embeddings indexing is being turned down in favor of grep-based retrieval.

Both .cursorignore and .gitignore are respected! This is true whether a search is served by the Instant Grep index or by regular ripgrep, and the Instant Grep index is built per-repo and stored locally only.

No, that limit belonged to the semantic index, not to grep. There’s no file-count ceiling on what’s searchable.

There’s no direct replacement for embeddable_files.txt. It was generated as a side effect of building the index, so with indexing gone, it’s no longer produced.

That said, the file explorer directly marks ignored files. In the IDE, any file covered by .cursorignore gets a block icon with a tooltip explaining why (“AI features disabled — File in .cursorignore”), and in the agents window, ignored files are shown dimmed.

IDE:

Screenshot 2026-07-22 at 14.31.18
Screenshot 2026-07-22 at 14.31.181034×236 29.1 KB

Agent Window:

Screenshot 2026-07-22 at 14.31.58
Screenshot 2026-07-22 at 14.31.58396×146 5.2 KB

Fair question! What we found in testing is that current models handle this well with grep: Instant Grep is fast enough that the Agent doesn’t bet on one seed, it searches several candidate terms in parallel, lists directories, and reads files to refine.

Like @maximep said above: if a specific request performs poorly, please report it with the request ID so we can look into it!

14

instant grep index is built per-repo and stored locally! based on this i have some question.

I’d love to understand more about how this actually works:

  • Indexing mechanism: What kind of index is being built (inverted index, trigram index, something else)? Is it a full-text index of every file, or does it just index file paths/metadata?
  • Storage format : When it says “stored locally,” what format is used? Is it a SQLite database, a custom binary format, flat files, or something else entirely?
  • Storage location: Where on disk does this data live (e.g., inside the project folder, in ~/.cursor, or an app-support/cache directory)? Is it per-project or global?
  • Update behavior: Does the index update incrementally on file save/change, or does it re-scan the whole repo periodically?
  • Size/performance : Roughly how much disk space does this add for a large repo, and does it respect .gitignore / .cursorignore when building the index?
15

Hey @imnulhaqueruman, good questions! A lot of this is written up in detail here: Fast regex search: indexing text for agent tools · Cursor

On the other points:

  • Where it lives: The binary files (not SQLite!) live In your repo’s git directory, under .git/cursor/. It’s per-repo, local only, never global. And since it sits inside .git, it’s never tracked or pushed. Delete the folder, and it’s gone.

  • How it updates: Incrementally. The index is anchored to a git commit, and your edits get layered on top of it, so there’s no periodic rescan. It will rebuild every once in a while if your working state has drifted far from the indexed commit (e.g., a big pull or branch switch), but not on a schedule.

  • Size. Ballpark, about half the size of the source it indexes.

  • Ignore rules: .gitignore is respected by construction (ignored files were never candidates for indexing in the first place, since the index is built from git-tracked content). .cursorignore is enforced on the access path, so cursor-ignored files won’t show up in results.

16

Hi Colin,

What if my organization uses subversion and not git for versioning, should I create a git repo in my project just to store the index?

Thank you

17

Hey @Enrico_Triolo!

Instant Grep is anchored to a git commit, so in a non-git project it simply doesn’t kick in and search falls back to plain ripgrep.

I wouldn’t recommend creating a git repo purely to get the index. It would only do anything if you actually committed your source into it, since the index is built from committed content.

20

@Colin I have another observation. In the output/tasks list, Cursor has two available services: Cursor Grep Service and Cursor Indexing & Retrieval. If Cursor’s indexing is down, why does Indexing & Retrieval still show as active?

Instead of semantic embedding-based indexing, Cursor is currently using a repository index for instant grep, storing this data inside .git/cursor/crepe . Does the Cursor Grep Service extension use this local index instead of the semantic embeddings?

22

Yes to your second question. Cursor Grep Service is what builds and queries that local index, and that’s the whole search path now - no embeddings involved anywhere in it. If a project has no index (not a git repo, or it hasn’t been built yet), the same searches fall back to plain ripgrep.

Cursor Indexing & Retrieval is a naming artifact. Those two entries aren’t two independent services, they’re two log channels from the same built-in retrieval component, and that component covers more than the old semantic index: local search, git context for the agent, and the file lookups the agent asks for. It starts up with the window either way, so seeing it in the Output list isn’t a signal that a semantic index is being built. The name is stale now that semantic indexing is wound down.