Cursor IDE crash during agent work

[rsb]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor crashed during a long thinking / file editing cycle with the attached error dialog. I was able to reload Cursor and resume work after nudging the agent.

Steps to Reproduce

The issue happened during an extended work cycle using Opus 4.5 to read and modify files.

Edit: This has now happened twice, and Cursor lost some edits that had been made to files before the crash.

Edit again: I now have some insight into what caused this – this is a local Cursor instance using a remote SSH session, however the Cursor IDE used up staggering quantities of local disk space, and the following error was captured in the logs (… markings below were six character alphabetic strings)
[error] Error resolving SSH authority [Error: ENOSPC: no space left on device, mkdtemp ‘/tmp/cursor-ssh-…’
at async Object.mkdtemp (node:internal/fs/promises:1175:10)
at async t.RemoteSSHResolver.setupAskpassServer (/home/cursor/.cursor/extensions/anysphere.remote-ssh-1.0.35/dist/main.js:2:396386)
at async /home/cursor/.cursor/extensions/anysphere.remote-ssh-1.0.35/dist/main.js:2:405341] {
errno: -28,
code: ‘ENOSPC’,
syscall: ‘mkdtemp’,
path: ‘/tmp/cursor-ssh-…’
}

Looking at the disk analyzer, the culprits appear to be .config/Cursor/User/globalStorage/{state.vscdb, state.vscdb.backup} with these two subdirectories taking up 11.4GiB and 10.7GiB respectively.

Half an hour or so before this error occurred, my system gave me a low disk space warning with ~750MiB remaining, so the IDE chewed through a huge amount of disk space in a very short time.

Edit 3: Just happened again, this time with 5.6GiB of free disk space on the local machine, so perhaps the disk space issue isn’t the root cause?

Expected Behavior

The Cursor IDE shouldn’t crash.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Version: 2.5.25
VSCode Version: 1.105.1
Commit: 7150844152b426ed50d2b68dd6b33b5c5beb73c0
Date: 2026-02-24T07:17:49.417Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.8.0-101-generic

For AI issues: which model did you use?

Opus 4.5

For AI issues: add Request ID with privacy disabled

3995e31f-76b9-4b71-bf2a-469e4a151a00

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. It’s especially helpful that you tracked it down to state.vscdb as the cause.

There are actually two issues here:

1. state.vscdb grows to a huge size

11,4 GB plus a 10,7 GB backup is definitely not normal. Other users are seeing the same thing: Cursor state.vscdb growing at 1 GB in a day. As a temporary workaround:

• Fully quit Cursor
• Delete state.vscdb.backup (it’s just a backup, safe to remove)
• Open state.vscdb in DB Browser for SQLite: https://sqlitebrowser.org/ and run VACUUM
• If VACUUM doesn’t reduce the size, can you check which tables are taking up the most space? That’ll help us understand what’s growing

2. SSH session crashes while the agent is running

The third crash with 5,6 GB free disk space confirms your suspicion, disk space isn’t the only cause. Other users are also reporting similar SSH plus agent crashes: Cursor Crashing whenever connected to SSH. The team is aware of SSH connection stability issues, but there’s no ETA yet.

A couple questions:

• What’s the project size on the remote machine?
• Roughly how long did the agent session run before each crash?

Let me know if the crashes still happen after cleaning up state.vscdb. That’ll help us figure out if these two issues are related.

[Insta241FLO]

I had the same issues , and i paid 3x more money for my project because on the middle he start to crash , I try to Implement something like “ back up “ but still keep crashing and even with backup doesn’t take he’s job from he was stopping, is anything but what we can do in this case ?

[rsb]

Hi Dean,

Very helpful. By project size, I assume you mean Cursor’s project size(s), not the size of the actual repository tree that Cursor is working on. In this case, these values are:

20K home-ubuntu
31M home-ubuntu-development

With respect to the state.vscdb database, here are the table sizes in bytes before VACUUM:

SELECT SUM(“pgsize”) FROM “dbstat” WHERE name=‘cursorDiskKV’;

Before: 11999174656

SELECT SUM(“pgsize”) FROM “dbstat” WHERE name=‘ItemTable’;

Before: 3493888

Unfortunately I wasn’t able to execute these queries after the VACUUM operation (Result: no such table: “dbstat”), although puzzlingly, SELECT * from dbstat;returned data. I didn’t have enough time to troubleshoot this, but will happily accept further guidance and provide additional info.

To your final question, I’d say that about an hour elapsed between crashes. I haven’t yet tried running Cursor after the state.vscdb cleanup, but will advise if it happens again. Good luck!

Edit: I forgot to mention that state.vscdb didn’t seem to change after the VACUUM operation, despite running for a while - still around 12GiB on disk.