Cursor opens a second window with a workspace storage error when I run `cursor -r ./somefile.txt` from a terminal while another Cursor window is already open

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am already in one open Cursor window for the workspace at:

C:\Users\spect\workspace\freemote\app

From a terminal, I run:

cursor -r ./somefile.txt

Instead of reusing the existing window, Cursor opens a new window, and that
new window shows the local storage error modal for:

C:\Users\spect\AppData\Roaming\Cursor\User\workspaceStorage\db10f6778f2ed5e2b1a92551d8789dc0\state.vscdb

I deleted the affected workspaceStorage directory and rebooted, but the issue
still reproduces.

Logs show:

  • Error mutex already exists
  • SQLITE_BUSY: database is locked
  • EBUSY: resource busy or locked while trying to rename state.vscdb to
    state.vscdb.corrupted...

Permissions on the folder and file look normal, and my user has full control.

Steps to Reproduce

  1. Open Cursor normally with the workspace
    C:\Users\spect\workspace\freemote\app.
  2. Keep that Cursor window open.
  3. From a terminal, run:
cursor -r ./somefile.txt
  1. Instead of reusing the existing window, Cursor opens a new window.
  2. That new window shows the storage error modal for:
    ...\workspaceStorage\db10f6778f2ed5e2b1a92551d8789dc0\state.vscdb

Expected Behavior

cursor -r ./somefile.txt should reuse the currently open Cursor window and
open the requested file there. It should not spawn a new window, and it should
not trigger a workspace local storage error.

Cursor should either:

  • open the workspace normally, or
  • detect the storage DB is bad or locked, recreate it safely, and continue
    launching without blocking the workspace.

Screenshots / Screen Recordings

Screenshot 2026-04-03 115101.png
Screenshot 2026-04-03 115101.png641×286 14.2 KB

Operating System

Windows 10/11

Version Information

Version: 3.0.9 (user setup)
VSCode Version: 1.105.1
Commit: 93e276db8a03af947eafb2d10241e2de17806c20
Date: 2026-04-03T02:06:46.446Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Additional Information

I verified the file and folder permissions are not the issue:

  • SYSTEM: Full control
  • Administrators: Full control
  • my user account: Full control

The DB files are not read-only.

This makes it look like an internal Cursor locking, single-instance, or
workspace-storage bug rather than a filesystem ACL problem.

Relevant log messages:

  • Error: Error mutex already exists
  • [storage state.vscdb] exec(): Error: SQLITE_BUSY: database is locked
  • [storage state.vscdb] open(): Unable to open DB due to Error: SQLITE_BUSY: database is locked
  • EBUSY: resource busy or locked, rename '...state.vscdb' -> '...state.vscdb.corrupted....'

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, great bug report, it already includes everything we need.

This looks like a bug in the IPC single-instance handoff on Windows. The second Cursor process can’t pass its arguments to the first one and fully launches instead, which causes a conflict over state.vscdb. I’ve shared this with the team. There’s no ETA yet, but your report will help with prioritization.

As a temporary workaround, you can open files without -r, just use cursor ./somefile.txt. If your current window is already open on the same workspace, the file should open in that window. Let me know if this also reproduces the issue.