Symptom
When trying to create or update a file inside a UNC/sshfs path like \sshfs\user@host..., the write operation sometimes fails with:
EPERM: operation not permitted, mkdir ‘\sshfs...\SGX_project\EthSignerEnclave\e2e_mvp_hybrid’
At the same time:
Reading files from \sshfs... works consistently.
Writing to \sshfs... is possible in general (e.g., creating a new file in a new subfolder inside e2e_mvp_hybrid/ succeeds).
The error looks like Cursor is trying to mkdir an existing parent directory and failing with EPERM.
Minimal repro (high-level)
Open a workspace located on \sshfs\user@host\path\to\repo (sshfs mounted on Windows as a UNC share).
Try to write/patch an existing file in an existing folder, e.g.:
update \sshfs...\e2e_mvp_hybrid\e2e_runbook_regtest.sh
or add \sshfs...\e2e_mvp_hybrid\newfile.txt
In contrast, adding a file under a new nested directory succeeds, e.g.:
add \sshfs...\e2e_mvp_hybrid_tmp_random\test.txt
Internal diagnosis (based on observed behavior)
There appears to be an “ensure parent directory exists” step in the write pipeline that:
incorrectly decides the parent directory is missing, or
incorrectly normalizes/resolves the UNC path and calls mkdir incorrectly, or
calls mkdir on \sshfs...\e2e_mvp_hybrid even when updating an existing file,
and on sshfs/UNC this mkdir returns EPERM (instead of behaving as a no-op / “already exists”).
Key signal: creating a new subfolder + file works, so the share is writable; the failure is strongly correlated with an erroneous mkdir on an already-existing directory (or on a wrongly resolved parent path).
Expected behavior
Updating an existing file should not attempt to create its parent directory.
Creating a new file should only mkdir -p directories that truly do not exist, and should correctly handle “already exists” on UNC/sshfs.
Actual behavior
Cursor intermittently attempts mkdir on an existing directory (or the wrong parent) and fails with EPERM.
Workaround
Use a staging directory: write changes into a new subfolder (e.g. _cursor_patched/…), then manually move the file into place on the Linux side (mv). This is disruptive to normal development flow.
Environment
Windows UI
Project located on Linux via sshfs, exposed to Windows as \sshfs... UNC path
Steps to Reproduce
Open the workspace at \sshfs\user@host\path\to\repo (the sshfs is mounted as a UNC share on Windows).
Try writing/patching an existing file in an existing folder, for example:
update \sshfs...\e2e_mvp_hybrid\e2e_runbook_regtest.sh
or add a file directly to \sshfs...\e2e_mvp_hybrid\newfile.txt
Get an EPERM error … mkdir ‘\sshfs...\e2e_mvp_hybrid’.
However, if you add a file to a new nested directory, for example:
add \sshfs...\e2e_mvp_hybrid_tmp_random\test.txt
the operation succeeds.
Expected Behavior
Expected behavior
When updating an existing file: do not mkdir at all (the parent already exists).
When adding a file: mkdir -p only for directories that actually do not exist, and correctly handle “already exists” errors on UNC/sshfs.
I can see the screenshot with the EPERM error during ApplyPatch. Cursor is trying to mkdir a directory that already exists e2e_mvp_hybrid when writing to a UNC path.
Your analysis is spot on. It looks like the file write pipeline on Windows doesn’t handle UNC/sshfs paths correctly. It calls mkdir even when the directory already exists, and sshfs returns EPERM instead of “already exists”.
I’ve passed this along to the team. Your details (the UNC path specifics, and the pattern that “new subfolders work, existing ones don’t”) will help them dig in.
For now, using a staging directory as a workaround is the only option. I know it’s annoying, but it keeps you unblocked.
Thank you very much for the quick response. I hope this gets fixed.
Regarding the current situation:
I tried the latest update.
The bug wasn’t fixed.
I just tried creating a file directly in the existing e2e_mvp_hybrid/, and the operation failed again with:
EPERM: operation not permitted, mkdir ‘\sshfs…\e2e_mvp_hybrid’
That is, the runtime still tries to mkdir the parent directory even when it already exists, and SSHFS prevents this.
The workaround is still the same: write to a new subfolder (unique each time) and then cp -f to the target file.
When trying to create/edit a file directly in the root or inside of an existing directory (Network Unit attached with sshfs,a few weeks ago this scenario works properly) using the write tool, Cursor attempts to run mkdir on the parent directory even though it already exists. This results in a permissions error (EPERM).
Steps to Reproduce
Have an existing directory (example: X:\PROJECT_ROOT)
Try to create a file directly in the root of that directory using the write tool
Expected Behavior
The file should be created without any issues, since the parent directory already exists.
Operating System
Windows 10/11
Version Information
2.4.27 (user setup)
Additional Information
The issue does NOT occur when trying to create a file inside a non-existing subfolder (for example, with a random name).
In that case, Cursor correctly creates the folder and then creates the file.
The bug seems to be in the logic that checks whether the parent directory exists before trying to create it.
I’ve found a workaround for this bug without having to work locally!!!
Since I saw that the problem was that Cursor doesn’t work well with SSHFS network drives, what I did was create a symlink in my local directory pointing to the shared folder using mklink /D. Then, in the multiroot workspace, I set the local directory C:\xxx\xxx\xxx\symlink_backend, and now it works perfectly!
Issue Still Occurring - EPERM Error with SSHFS on Windows (Started Feb 5th)
Issue Update
I want to report that this issue is still occurring, and it appears to have gotten worse starting around February 5th, 2026.
My Setup:
Windows 10/11 with SSHFS-Win
Mapped network drive: S:\ pointing to \\sshfs.r\[email protected]\path\to\dir\
Cursor was previously able to write to these files before Feb 5th
What Changed:
As of February 5th, 2026, all file write operations fail with the same EPERM error when using Cursor’s Write and StrReplace tools. For the output below, the “dev” directory exists and I am trying to write to a file in \dev.
Error: EPERM: operation not permitted, mkdir ‘s:\dev’
Testing Results:
I tested various scenarios to narrow down the issue:
Write to C:\ drive - Works perfectly
Write tool to S:\ (SSHFS) - Fails with EPERM
StrReplace tool to S:\ (SSHFS) - Fails with EPERM
Shell commands with required_permissions: [“all”] - Works (bypasses sandbox)
Manual editing in Notepad - Works while Cursor is running
Diagnosis:
This appears to be a sandbox policy change that was introduced around February 5th. The sandbox now blocks write operations to mapped network drives (including SSHFS) unless the sandbox is completely disabled with required_permissions: [“all”].
Impact:
The Read tool works fine on SSHFS drives
All editing tools (Write, StrReplace) are blocked by the sandbox
The symlink workaround mentioned by @Soykheabro on Feb 4th may help, but it doesn’t address the root cause
This significantly impacts workflows for developers using remote filesystems via SSHFS
Request:
Since this worked perfectly before February 5th and suddenly stopped, this appears to be a regression introduced in a recent Cursor update. Could the team investigate what changed in the sandbox permissions around this date?
Write to C:\ drive - Works perfectly
Write tool to S:\ (SSHFS) - Fails with EPERM