I’m a new user to Cursor, it’s awesome, however this bug really disrupts my flow.
While unstaged stages are shown correctly, staged changes are not visible in the gutter when I’m viewing the file in the editor. This is very disruptive, because I have to continuously jump back and forth from the file to the diff view to spot whether a line has changed.
I now find a similar issue (Cannot see staged changes in gutter - #5 by deanrie), probably the same as what I’m reporting. However this issue has been closed it’s been more than 2 months and the bug persists.
Steps to Reproduce
Stage any changes in git, the changes should be shown in the gutter (with more “faded” colors compared to unstaged) but all staged changes should be visible in the file editor.
What happens instead: No staged changes appear anywhere in the gutter
Expected Behavior
Staged changes should be visible in the gutter (with more “faded” colors)
Hi! You’ve diagnosed this one correctly - it’s the same known gap as the earlier report you linked.
Cursor hasn’t yet ported the “Diff Decorations” gutter menu from upstream VS Code, which is what lets you show staged changes in the gutter (the dimmed/faded colors). Without it, a change drops out of the gutter once it’s staged, even though unstaged changes still show. So nothing is misconfigured on your end.
A practical workaround in the meantime: keep your changes unstaged until you’re ready to commit. Unstaged edits show in the gutter normally, so staging everything right before you commit (rather than incrementally) keeps the indicators visible while you work.
It’s a known limitation rather than a recent regression. I’ve re-raised it with the team so it’s back on the radar - I’ll follow up here if there’s an update. No ETA to share right now.
Thanks again for re-raising the issue but I don’t have any hopes for this. It’s clear to me that all development goes to the agents window and nobody bothers or cares about the editor view. I expect more bugs compounding in the edιtor view in the future, because all development is focused on the next best feature in agents view.
This is really disappointing, not so much the bug per se, more-so the fact the editor window is not getting any love because everybody is riding the AI hype train. It’s a pity, because I wanted to like Cursor because it is the best, not because it is the least bad option.
Yes, thanks for re-raising this. I actually had another thread when the first one was closed, 2 months ago or so. @deanrie at the time reported the issue to the team but still nothing…
Completely fair to be frustrated, and I won’t give you a canned answer here.
Honestly, a big part of why this has sat is demand. Our product team prioritizes largely by how many people are actively running into something and reporting it, and this gap hasn’t had a lot of that behind it. That’s not a satisfying answer when it’s clearly disrupting your flow, but it’s the real one. The most effective way to move it up is exactly what you and @rollo are doing: more people surfacing it in one place. I’ve re-logged it so it’s back on the team’s radar.
On the “only the agents window gets attention” point: I use the editor view all the time myself, so it’s genuinely not abandoned. This is a real gap that hasn’t been prioritized yet, which isn’t the same as nobody caring about it.
No ETA I can promise, but I’ll update this thread directly if the gutter work moves.
I have noticed this issue quite early. In VSCode, there is this feature, and I think it’s very good. However, whenever I use the cursor and want to view the code changes in the staging area, it becomes very uncomfortable to do so.
As I mentioned above, prioritization leans heavily on how many people are actively running into something, so each confirmation like yours pushes this up the queue.
To be clear: this is a real gap (the “Diff Decorations” gutter menu from VS Code isn’t ported yet), not anything misconfigured on your end. In the meantime, the workaround from my earlier reply still applies - keep your changes unstaged while you work and stage right before committing, since unstaged edits show in the gutter normally.
It’s logged and back on the team’s radar. No ETA I can promise, but I’ll update this thread directly if the gutter work moves.
This issue is now three moths old with similar issues referring to the same problem almost a year old.
I understand that many people want to commit code without reading it, but for the rest of us it would be really helpful to be able to see the staged changes in the gutter in the editor view.
@akittas you’re right that this has gone too long, and I’m not going to give you the same line back. I checked the current build directly: staged changes still can’t be shown in the editor gutter, there’s no setting or menu for it yet, so this is a real gap on our side and not anything on your end.
I can’t promise a date, but I’ve made sure it’s properly back in front of the team rather than sitting closed, and I’ve tied these repeated reports together so the demand is visible in one place. If it moves, I’ll post here.
The only thing that helps in the meantime is keeping edits unstaged while you work and staging right before you commit, since unstaged changes still show in the gutter. I know that’s a workaround, not the fix you actually want.
@mohitjain many thanks for your reply. However, I cannot stress how disappointed I am with this. In my workflow I use staged and unstaged changes to discern which of the agent changes I have approved (staged) vs which of the agent changes I still want to check (unstaged). The gutter view provides a nice overview for both of that and it has been missing in Cursor from the first day I installed it.
Almost one year has passed since the first reported issue mentioned this problem and this has been ignored since then. Even when issue was re-raised, it was again ignored. I’m a bit dumbfounded to realize that many people do not even use git in their workflow at all, because otherwise they would immediately spot this problem. This bug is critical to my day-to-day usage of git.
It seems to me that this would be quite a straightforward bug to solve, yet is being ignored since at least one year. I’m disappointed from two sides:
From the Cursor Team that ignores such an important bug which would probably be straightforward to solve (might I suggest using Cursor for it?)
From developers in general, who seem to have stopped reading their code and just keep prompting the LLM until the result looks reasonable enough. It is as if people have stopped caring about checking their code, so this doesn’t bother them.
@mohitjain thanks again, but not holding my breath for this.