Cursor 2.0 removes token and git commit references in chat

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

This update removes two heavily used features:

  1. Referencing tokens (like using a function definition token in chat instead of the whole file or selecting the line range.)
  2. Referencing a single git commit. The only git context available right now is the diff with main (which is useless in any staging based dev environment anyways)

Steps to Reproduce

Try to reference a token using @ or looking for a git branch

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.38
VSCode Version: 1.99.3
Commit: 3fa438a81d579067162dd8767025b788454e6f90
Date: 2025-10-29T20:45:40.883Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 25.0.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

8 Likes

Hey! For git, you can ask the agent to look at a commit - for referencing tokens - seeing what we plan to do here - referencing a file or the name of the method will also reliably work.

3 Likes

Git: fair, I imagine it can always run a command too, but I don’t always have the commit handy and navigation was smooth when looking for my commit inline in the chat.

Tokens: yes please. I don’t like polluting my context by giving full file, then sharing token name. Also takes longer, and it is a ā€œregressionā€ so hopefully not a pain to add back.

Thanks.

8 Likes

It is less usable. There does not seem to be any kind of autocomplete that helps here now, whereas before the context palette did help find git stuff. That is a big loss here with 2.0…just because the model can ā€œfigure it outā€, doesn’t mean that the way things are now still matches up with the DX we had before. The DX has declined in 2.0.

8 Likes

@andrewh if I wanted for model to ā€œfigure outā€ everything, I would be using CLI agent like codex (err.. cursor agent). You somehow think degrading IDE experience to the same bare-bones bottom line as CLI is a good idea.

6 Likes

bad update,need git commit ref come back

3 Likes

Expanding on this, on fi_FI layout whenever I try doing opt+2 for @ in the chat, it just takes me to a different editor. My keybinds haven’t changed, it still shows the following configuration for the key. Between the reference token issue and the busted mentions, Cursor 2.0 feels like it will have quite some teething pains. Looking forward to fixes and addressed regressions.

{
  "key": "alt+2",
  "command": "composer.selectSubComposerTab2",
  "when": "composerFocused"
}
1 Like

Same behaviour on sv_SE layout I’m afraid. Quite annoying.

You’ve broken a feature, and now you’re offering crutches to PARTIALLY restore functionality. Why would I make up a whole sentence with a request to find a specific commit and hope that the Agent can do it if earlier I could do this by pressing a few keybuttons?

3 Likes

When I asked the agent to look at a commit, providing it with a revision number, I got ā€˜I don’t have access to your Git history here’. How do I do this?

1 Like

@condor @andrewh @deanrie

Just want to say, there is ā€œagent capabilityā€, and there is ā€œdeveloper experienceā€ā€¦ I would offer that these two things are orthogonal, not mutually exclusive. Improved agent capability is great, always want to see a more capable agent: EXCEPT…when it means my experience as a developer declines.

Removal of DEVELOPER tools, with the only alternative being ā€œspend a lot more time typing out prompts, waiting on agent, and dealing with agent insufficienciesā€, is not an improvement in the product. The command palette, was one of the things about Cursor that WAS awesome. It gave us a lot of power, right at our fingertips, to do common things, VERY quickly, with minimal overhead, minimal time waste, minimal token waste. We need that. We want that.

In a general sense, I am not actually in favor of being pushed towards using the agent, to do things in the slow, meandering, trial-and-error, figure-it-out-step-by-step approach. Because to combat that, to keep the agent from wasting time and tokens (thus money!) trialing until it sorta figures something out, I either have to write a much more detailed prompt (which, when I am describing new tasks I do, but usually when it comes to git things, its once a task is already in progress and I need speed and brevity), or…I just have to resort to doing the work myself.

Fundamentally, i would MUCH prefer to have tools I can use, either through the command palette, or as an agent tool, that provide much more deterministic and reliable and consistent ways to perform common tasks. The loss of command palette tools is, IMO, a step in the wrong direction as far as DEVELOPER EXPERIENCE (DX) is concerned. It is now harder to do common tasks. This was already somewhat the case, because the command palette had been mostly broken for so long. But we were requesting the command palette be FIXED! Not decimated. I’m not sure why you guys chose the decimation route, but, it really has had an impact on productivity.

I’ll offer, productivity is 100% entirely what Cursor is about! :stuck_out_tongue:

An example of something I would really love to see in Cursor, that would GREATLY enhance DX and productivity:

A deterministic refactoring agent tool, that the models can call, to perform common refactoring tasks. Right now, refactoring generally costs a lot of tokens, a lot of time, and usually, unless the model performs flawlessly, a fair amount of rework until things are refactored properly. Even a simple thing, such as a rename of some commonly used code element, which can usually be done in seconds with a deterministic refactoring tool (check out JetBrains IDE, they have AMAZING refactoring tools for the developer), even when there might be thousands of references to said identifier….when done by an agent, the results are entirely non-deterministic. Things are often missed, often code elements only are updated, but other elements (say in strings, comments, etc….all factors that JetBrain’s refactoring tools account for) are skipped, not all code elements are always caught, sometimes refactoring changes are implemented incorrectly, etc. So agents are not great at refactoring. Often quite poor.

An agent tool that the models could call, such as rename_code_identifier is one of those kinds of things that greatly improve DX, increase productivity, reduce non-deterministic outcomes, and would overall improve the quality of your product.

Please don’t take the path of UI reductionism, when your product is designed for professionals performing a complex job day in and day out, and where cost is of constant concern. The more you reduce the value and utility of your ui, in favor of ā€œjust have the agent do itā€ when the models, while ok, are far from optimal or even viable in so many cases, the more you will decimate DX and developer productivity.

Another simple example: The removal of the brain icon next to the selected model. That has a HUGE impact! I don’t know if you guys understand the impact, but for multi-model users, not knowing AT A GLANCE whether we are on a thinking model or not, means we are constantly checking, meaning its reducing our productivity as we move the cursor to click on that model selector control, and scan to figure out which model we are actually on. It seems small, but its actually quite a big deal.

Ask him to use git commands in his terminal

1 Like

Haha: I asked it to look commit in the terminal, and here is its response:

If you want to review commit b4aa676dc575d595b0782a0ce586c7bb50fcb3a9, run these in your terminal:

  • Show the commit’s diff:

git show b4aa676dc575d595b0782a0ce586c7bb50fcb3a9

So, instead of doing it, it tells me to run a command. How is this an improvement? :puzzle_piece:

2 Likes
  • Are you in Agent mode?
  • Which model?

Agent mode, Auto model

I can no longer type @git and then reference a particular commit. Is this a bug?

No, it’s a feature of 2.0

1 Like

Git was removed intentionally??