Cursor New Versions Unable to Write to ImDisk Virtual RAM Disk Files (Permission Error)

Support Bug Reports
1

Describe the Bug

Hi everyone. I’ve found that the new Cursor versions released in recent months are unable to modify files stored on virtual RAM disks. It keeps showing permission errors. However, I can edit the same files normally using Notepad or other IDEs without any issues.
Here is my system environment information:
1、Windows 11 Pro 24H2 (26100.4484)
2、Cursor Version: 3.2.16 (user setup)
3、Virtual disk software: ImDisk Virtual Disk Driver
4、Relevant AI prompt / log information from the project

ASK:   
Did you encounter any write issues?

ANSWER:  
Yes, I ran into write issues at the beginning. The ApplyPatch tool mistakenly treated I:\新建文件夹\main.c as a directory, so the patch write failed. Later I switched to using PowerShell’s Set-Content -LiteralPath to write the file, and it successfully wrote the red-black tree code into main.c.
However, in your current IDE, main.c still shows only 2 lines total. The editor may not have refreshed yet. You can try reopening the file or refreshing File Explorer.

ASK:
My I: drive is a RAM disk created with ImDisk Virtual Disk Driver, which turns excess RAM into a virtual disk.

ANSWER:
Understood. This also explains the earlier anomaly: some of Cursor’s file tools may fail to correctly handle path validation for ImDisk virtual disks when parsing I:\新建文件夹\main.c, causing it to be misidentified as a directory or failing symlink verification.
But PowerShell can recognize it correctly:
I:\新建文件夹 exists
I:\新建文件夹\main.c exists
main.c is not a directory

Therefore, going forward, when I need to modify files on the I: drive, I will prioritize using PowerShell’s -LiteralPath method for writing to avoid path parsing issues.

Steps to Reproduce

1、On Windows 11 Pro, create a virtual disk using the ImDisk Virtual Disk Driver.
2、Create a folder and a main.c file in the root directory of this virtual disk.
3、Open this folder with Cursor and have the AI write an algorithm (for example, a red-black tree).
4、Wait a moment, and Cursor will report no write permission.

Operating System

Windows 10/11

Version Information

Cursor Version: 3.2.16 (user setup)
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
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.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the detailed report. We couldn’t reproduce this setup locally, and there are two possible confounding factors in the thread that we should separate:

  1. ImDisk virtual disk (unusual file system)
  2. Chinese characters in the path (新建文件夹)

Could you run two quick control tests so we can tell what exactly is breaking writes?

  • Test A: On the same ImDisk drive, create a folder with an ASCII-only name, for example I:\test\main.c, then ask Agent to write something there.
  • Test B: On a normal C: drive, create the same folder C:\新建文件夹\main.c and repeat the same request.

Also a couple of questions:

  • What file system is the ImDisk volume formatted as (NTFS / FAT32 / exFAT)?
  • Can you paste the exact error text from Cursor (not an LLM summary)? You should see it in the expanded tool call in chat, or in Cmd+Shift+J then Console after going to Help > Toggle Developer Tools.
  • The Request ID from the chat where ApplyPatch failed would also help (top right of the chat > Copy Request ID), if Privacy Mode is off.

With that info, I can pinpoint where path resolution is failing and escalate it to the right team.

5

Thank you very much for your help.

  1. The ImDisk volume is formatted with NTFS .
  2. Test A

    • Request Id: 008f602d-35b7-4b3c-b246-cb40e8f2ded7

    • Console Log:

      Test A Console.txt (42.2 KB)

  3. Test B

    • Request Id: e9136186-0743-4e1d-9ff4-f18de38ac92f

    • Console Log:

      Test B Console.txt (62.9 KB)