Git Changes list corrupts while scrolling

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In the IDE Window, the Git Changes list corrupts while scrolling. Rows paint on top of each other: file names overlap, and red and green diff text from one file appears on another row. The header can still say the correct file count (for example, “Git Changes (15 files)”) while the list itself is unreadable.

Closing the Git Changes tab and opening it again leaves the corruption in place. Quitting Cursor and launching it again restores a normal list.

Steps to Reproduce

Open a workspace that has a multi-file git diff.
In the IDE open Git Changes.
Scroll the file list up and down. This does not happen on every scroll. It shows up after scrolling for a while.
Watch for overlapping rows and diff colors drawn across the wrong files.
Close the Git Changes tab and open it again. The list stays corrupted.
Quit Cursor completely and relaunch it. The list renders correctly.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.21.16 (Universal)
VS Code Extension API: 1.128.0
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
Date: 2026-09-19T06:43:22.276Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey @nick_s, thanks for the detailed report, the screenshot helps a lot.

We can see what is happening here. The “Git: Changes” view reuses row templates as you scroll, and after a while it can start reusing them with the wrong file’s header and height, which is what produces the duplicated file names and the mixed red/green content. This is also an issue in upstream VSCode, however I’ve also flagged this to our team.

In the meantime you do not need to fully quit Cursor to clear it. Open the Command Palette (Cmd+Shift+P), run “Developer: Reload Window”, and the list should render correctly again.

Thanks for the quick response, Colin! Would be looking forward to a fix