The editor could not be opened due to an unexpected error: Unable to read file

I just installed Cursor. It opened my VSCode to run me through the ‘Welcome’ steps. Although, none of my files are opening and I can’t see any code at all. All I see is this:

The editor could not be opened due to an unexpected error: Unable to read file ‘>>>>>>myfilepath<<<<<<<’ (NoPermissions (FileSystemError): An unknown error occurred. Please consult the log for more details.)

I did nothing besides install Cursor, sign into my account, and do whatever the instructions told me to.

@SamuelKatsaros I’m facing the same issue, did you fix the issue? Can you please help

I am still having same issue in the windows 10

I have this issue as well, when I’m using the Cursor CLI to open a file on Google Drive, e.g.
cursor foobar2.txt. However, I’m able to use File/Open in Cursor to load the file, and after that, the file can be loaded from the CLI as expected.

In MacOS at least, adding the Privacy & Security, Full Disk Access permission to Cursor resolves this issue.

But, can Cursor come up with a better solution, e.g. requesting a grant from MacOS for programmatic access to a specific folder or tree within Google Drive?

This is the error from Cursor’s renderer.log:

2025-04-16 10:48:04.020 [error] Unable to read file '/Users/xyz/Library/CloudStorage/[email protected]/My Drive/somefolder/foobar2.txt' (NoPermissions (FileSystemError): An unknown error occurred. Please consult the log for more details.): Error: Unable to read file '/Users/xyz/Library/CloudStorage/[email protected]/My Drive/somefolder/foobar2.txt' (NoPermissions (FileSystemError): An unknown error occurred. Please consult the log for more details.)
    at L1i.F (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:4855:66190)
    at Object.error (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:4855:66336)
    at Object.onError (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:51:10742)
    at vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:51:9914
    at vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:51:11922
    at Array.forEach (<anonymous>)
    at X$i.h (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:51:11911)
    at X$i.error (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:51:11672)
    at zae.value (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:4855:76686)
    at M.B (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:49:748) Unable to read file '/Users/xyz/Library/CloudStorage/[email protected]/My Drive/somefolder/foobar2.txt' (NoPermissions (FileSystemError): An unknown error occurred. Please consult the log for more details.)
2025-04-16 10:48:04.020 [error] [File Watcher (node.js)] Failed to watch /Users/xyz/Library/CloudStorage/[email protected]/My Drive/somefolder/foobar2.txt for changes using fs.watch() (Error: EPERM: operation not permitted, watch '/Users/xyz/Library/CloudStorage/[email protected]/My Drive/somefolder/foobar2.txt')

ChatGPT seems to think that it’s a MacOS permissions problem:

This often boils down to macOS privacy and sandbox rules (TCC) distinguishing between:
	1.	User‑mediated file opens (via a standard File > Open dialog), which Apple generally grants permission for automatically because the user explicitly picked a file through a system dialog, and
	2.	Programmatic or CLI calls (like cursor /path/to/file.txt), which require the app to already have permission to read that file path.

In other words, when you use Cursor’s GUI “File > Open,” macOS treats it as a direct, user‑initiated open, so it’s allowed even if the app lacks broader file permissions. By contrast, the CLI call is an app‑initiated file access without the user picking a file in a system dialog, and macOS may block or partially sandbox that access—especially inside a “protected” location like a Google Drive folder managed by Apple File Provider.

Hence, you see “NoPermissions (FileSystemError)” when launching from the CLI, but no issue when opening the same file through the GUI. Typically, giving Cursor Full Disk Access (or enabling relevant toggles under “Privacy & Security” → “Files and Folders” for Google Drive) will unify these behaviors, so the CLI can open the file just as easily as the GUI.

same issue on windows 10, is this a windows specific issue?