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.
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:
ImDisk virtual disk (unusual file system)
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.
Test B is not running on the C:\ drive. In the log I see Cannot resolve workspace root, using as-is: i:\新建文件夹, so this is the same ImDisk drive again, just an opened folder with a Chinese name. To separate ImDisk from the Chinese characters, please create a folder on the physical C:\ drive (for example C:\test_cn\新建文件夹\main.c) and repeat the test there.
198.18.0.0/15 is an RFC 2544 reserved range, Cursor servers are not actually on that IP. This means something on the system is intercepting Cursor DNS or traffic. Most common causes are:
An antivirus with network inspection (Kaspersky, 360, Huawei HiSec, etc.)
Hosts file C:\Windows\System32\drivers\etc\hosts entries for cursor.com or cursor.sh
A corporate proxy or VPN
DNS hijacking, for example on the router
This is a separate issue, and it can totally explain permission errors. If the backend is not reachable, file edit operations can fail. Can you run Cursor Settings > Network > Run Diagnostics and share the result?
A third-party extension buuug7.GBK2UTF8 is crashing in the Test B log with ENOENT. Please try disabling it and rerun the test.
What I need from you: the exact ApplyPatch error text from the expanded tool call in the chat, not a summary from the model. Also please clearly confirm if the write in Test A succeeded or failed.
My guess is the main cause here is not ImDisk, but network interception. Let’s solve that first, then we’ll know if there is still an ImDisk-specific problem.
My guess is the main cause here is not ImDisk, but network interception. Let’s solve that first, then we’ll know if there is still an ImDisk-specific problem.
Regarding the guess you provided, I have a different view: there are indeed some network issues, but they should not be the reason for the write failure. At least, one thing is clear: as long as the project is created on a partition not created by ImDisk, Cursor can write to the specified files very normally, with no permission issues.
If, as you said, the write issue is caused by the network, then I’m having trouble understanding why projects on other partitions not created by ImDisk work normally, while the ImDisk-created partition has permission issues.
You’re right, thanks for the clean C: test. It really rules out the idea about Chinese characters and confirms the variable factor is ImDisk. On the network point, I agree that 198.18.0.43 ETIMEDOUT doesn’t explain permission errors on write, since writing to C: on the same machine works fine. That’s a separate issue with its own cause (AV, proxy, hosts), and we can debug it in parallel.
To fully close the loop on ImDisk, I still need two things:
The result of Test A (I:\test\main.c, ASCII path on the ImDisk drive). Did the write succeed, or did it fail with the same permission error? This is critical since it separates ImDisk by itself from ImDisk plus something else.
The exact ApplyPatch error text from the expanded tool call in the chat, not a model summary. It should look like something like ApplyPatch failed: ... or Write permission denied: .... Can you expand the tool call in the chat where it failed and copy the text from there?
With these two items, I can report the exact problem signature internally. I couldn’t reproduce the ImDisk setup locally, so having complete data matters more than usual here.
The test for “I:\test\main.c” also shows the same write permission error.
Below is the key chat log from this test ( Request ID: d66db355-d1a7-4894-a2e8-035fc734c3a0 ).
I’ll inspect main.c to see the current scaffold and then fill in the binary tree algorithm in the same style.
Explored 1 file
main.c is just a minimal “Hello, World!” program, so I’m going to replace it with a small, self-contained binary search tree implementation: insert values, traverse them in sorted order, search, and clean up memory.
Edit attempted
Write permission denied: Itestimain.c: Write blocked: cannot verify Itestimain.c --EISDIR: EISDiR: illegal operation on a directory,
realpath 'I:\test\main.c'.
Identifying path issues 1s
dentifying path issues
I’m thinking there’s a strange path issue, possibly because I’m working with Windows path formats, which might be causing a tool problem. It’s making me wonder if I need to use something like /i/test instead. I think trying a glob pattern could help me sort this out. Overall, I just need to ensure that I’m handling paths correctly to avoid further complications.
The first write attempt hit a path resolution issue, so I’m going to locate the workspace path as the editing tool sees it and apply the same change there.
......
Troubleshooting file operations 1s
Troubleshooting file operations
I need to edit a file using ApplyPatch, but it's not working. The tool advises against using shell commands for file operations, though. I might consider using Powershell's Set-Content, but I should be utilizing specialized tools instead. There’s no file writing option aside from ApplyPatch. Maybe the path requires forward slashes or should be an absolute path. I’m wondering if the backslash is causing issues, so I’ll try "I:/test/main.c."
Edit attempted
Write permission denied: I:/test/main.c Write blocked: cannot verify I:\test\main.c - - EISDIR: EISDIR illegal operation on a directory, realpath 'I:\test\main.c'.
ImDisk + ASCII path → fails with the same EISDIR ... realpath 'I:\test\main.c'
C: + Chinese chars → succeeds
So encoding and network are ruled out. The variable is ImDisk. I agree on the ETIMEDOUT to 198.18.0.43, that’s a separate issue like AV, hosts, proxy and it doesn’t explain permission errors on local writes.
Bug summary: the pre-write verification calls the standard Node fs.realpath() on the path before writing. For files on an ImDisk volume it returns EISDIR, even though it’s a normal file. Notepad and PowerShell Set-Content -LiteralPath write fine. Under the hood, Node on Windows resolves the path via Win32 GetFinalPathNameByHandleW plus reparse points. Somewhere in that stack, ImDisk returns something that gets treated as a directory. The exact root cause is outside our code, it’s either the ImDisk driver or Node’s Windows bindings.
I have the signature, Request ID, and the control tests, so I’ll file an internal bug. I can’t give an ETA.
Workaround for now: keep your working copy on a physical disk for projects where agent write is needed. If you want RAM disk speed, you can try a different virtual disk driver like OSFMount or Dataram RAMDisk. They implement NTFS a bit differently and realpath might work. No guarantees, but if you try it, let me know the result. That’ll help narrow down the cause.
Thank you very much. For now, I will only consider using ImDisk.
I have been using Cursor to write code on an ImDisk virtual disk partition for a long time without any issues. The problem only started appearing after I updated to a certain version two or three months ago. I’ve been very busy and only recently got around to sharing this issue.
Is it possible for me to downgrade to a Cursor version from two or three months ago? If I remember correctly, during this period there was one Cursor version that enforced an upgrade — you couldn’t use Cursor unless you updated.
You can grab older builds right here: Cursor · Download. There’s an archive of previous Windows versions.
One note: the backend has a minimum supported version. If you install a build that’s too old, AI features may stop working. That forced upgrade you remember was for this reason. So a downgrade can work as a temporary workaround, but the next time the minimum version is raised it may ask you to upgrade again.
Before running an older build, I’d suggest turning off auto-update so it doesn’t pull a new update: Settings > Application > Update Mode > Manual.
If you find the latest version that still works, please share it in the thread. It’ll help narrow down the regression.