Cursor3+Remote ssh extension+degraded performance bug

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

TL;DR: during degraded performance / server issues, Cursor tries to continue working reading local files instead of remote files. Not sure if this is a Cursor bug or a remote ssh extension bug.

Not a big deal but I think it is worth reporting as it may help also in debugging other bugs. During the degraded performance minutes ago I checked the cursor logs on the console and saw this (project name redacted):

[main 2026-05-12T02:11:37.502Z] [FileAppendMainService] Failed to append to file: /root/.cursor/projects/root-project-folder-name/agent-transcripts/78a86311-688e-4a63-8308-68f0f98c49b5/78a86311-688e-4a63-8308-68f0f98c49b5.jsonl Error: EACCES: permission denied, open '/root/.cursor/projects/root-project-folder-name/agent-transcripts/78a86311-688e-4a63-8308-68f0f98c49b5/78a86311-688e-4a63-8308-68f0f98c49b5.jsonl'
    at async open (node:internal/fs/promises:636:25)
    at async writeFile (node:internal/fs/promises:1205:14)
    at async dv.appendFile (file:///home/neo/.tmp/appimage_extracted_7108eb17451a17ce229696e2d8de5179/usr/share/cursor/resources/app/out/main.js:138:16888) {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/root/.cursor/projects/root-project-folder-name/agent-transcripts/78a86311-688e-4a63-8308-68f0f98c49b5/78a86311-688e-4a63-8308-68f0f98c49b5.jsonl'
}

EACCES/permission denied wasn’t possible because I’m working with remote ssh extension and there is only 1 user on that server, root…

I made a test, locally I created that folder path with mkdir -p and give 777 permissions to each folder in the path. Then Alt+Tab to Cursor and clicked “Try again”:

[main 2026-05-12T02:33:14.630Z] [FileAppendMainService] Failed to append to file: /root/.cursor/projects/root-project-folder-name/agent-transcripts/78a86311-688e-4a63-8308-68f0f98c49b5/78a86311-688e-4a63-8308-68f0f98c49b5.jsonl Error: ENOENT: no such file or directory, open '/root/.cursor/projects/root-project-folder-name/agent-transcripts/78a86311-688e-4a63-8308-68f0f98c49b5/78a86311-688e-4a63-8308-68f0f98c49b5.jsonl'
    at async open (node:internal/fs/promises:636:25)
    at async writeFile (node:internal/fs/promises:1205:14)
    at async dv.appendFile (file:///home/neo/.tmp/appimage_extracted_7108eb17451a17ce229696e2d8de5179/usr/share/cursor/resources/app/out/main.js:138:16888) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/root/.cursor/projects/root-project-folder-name/agent-transcripts/78a86311-688e-4a63-8308-68f0f98c49b5/78a86311-688e-4a63-8308-68f0f98c49b5.jsonl'
}

Now the failure is ENOENT (file not found), indicating that indeed Cursor was trying to read the path at the local machine.

Not a big deal, when server issues stopped, “Try again” this time works and you get to read remote files instead of locals.

Steps to Reproduce

In order to trigger this bug you need to be using remote ssh extension + Cursor 3 agents window + something must happen, either connectivity issues I guess o cursor status page indicating some problems.

When the connectivity issues are fixed o cursor status page indicate degraded performance, like a few minutes ago

Operating System

Linux

Version Information

Version: 3.3.30
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: glass
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: Linux x64 6.1.0-38-amd64

Additional Information

I’m using x11docker-cursor, which is gui-cursor inside docker , but doesn’t affect the issue.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. The logs, repro steps, and your analysis around mkdir -p plus ENOENT really helped confirm what’s going on.

This fits a known class of bugs: when there are connectivity issues with Remote SSH and Glass agents, the window workspace context can flip from remote to local. Then any code that uses user home or workspace paths starts resolving them against the local filesystem. In this case, transcript writing is using a remote-derived path (/root/...), but the write happens locally. That’s why you see EACCES, and after you create the folder manually, you get ENOENT.

We’re tracking the issue, but I can’t share an ETA yet. If this still happens after the next updates, let me know in this thread and we’ll take another look.

8

Hey @J_a1, following up. That workspace context flip on Remote SSH, where transcript paths like /root/... were getting sent to the local machine and causing EACCES, and then after mkdir -p it became ENOENT, is fixed in stable 3.4.20. Update Cursor and the issue should go away.

If you still see the same symptom after updating in a degraded scenario, reply in this thread and we’ll take another look.