Agent Write permission denied on .cs files + NTFS Length +1024

Support Bug Reports
, , ,
1

Describe the Bug

Cursor Bug Report: Agent cannot StrReplace/Write existing .cs files + NTFS Length inflated by +1024

Environment

  • OS: Windows 10/11 (build 26100)
  • Cursor: 3.14.7
  • Workspace: C:\Project\code\LinuxDeploy (local NTFS, not OneDrive folder)
  • Sandbox config: ~/.cursor/sandbox.json type=insecure_none
  • Agent approval mode: unrestricted / insecure_none
  • Extensions involved: anysphere.csharp (reproduces with and without; disabling LS reduces but does not eliminate size inflation)
  • Reconfirmed: 2026-08-03 — Agent StrReplace on healthy .cs (size==read) still returns Write permission denied

Bug A — Agent file tools fail on .cs

Symptoms

  • StrReplace / Write on existing .cs → Write permission denied
  • Read on .cs created outside Cursor (e.g. PowerShell) → Permission denied
  • Same operations on .md / .txt / .csproj in the same folder → OK
  • Creating a new .cs via Write → OK
  • Terminal/PowerShell can read/write the same .cs paths without error
  • OS ACLs are normal (Authenticated Users: Modify; not ReadOnly)

Minimal repro

  1. Open any folder containing .cs files in Cursor Agent mode
  2. Ask agent to change one line in an existing .cs via normal edit tools
  3. Observe: Write permission denied
  4. In terminal: overwrite the same file → succeeds
  5. Ask agent to edit README.md → succeeds

Bug B — .cs file Length becomes readableContent+1024

Symptoms

  • FileInfo.Length / :$DATA stream length is exactly 1024 bytes larger than bytes returned by File.ReadAllBytes
  • git add fails: error: short read while indexing ...
  • git hash-object may still succeed
  • Inflating process correlates with Cursor/anysphere.csharp LanguageServer activity, but can recur even after disabling the extension folder
  • Reproduces across many project .cs files; newly written tiny probes sometimes stay healthy until touched by Cursor tooling

Minimal repro

  1. Ensure a .cs file has size == read
  2. Use Cursor (open solution / agent / filesync) against the project
  3. Recheck: many .cs show size = read + 1024
  4. git add path/to/File.cs → short read

Impact

Agent cannot reliably edit C# source with normal tools; developers are forced to use shell workarounds. Git indexing breaks intermittently. Affects multiple local projects, not limited to one repo.

Workarounds tried

  • Closed Visual Studio: no fix
  • Set sandbox insecure_none + added workspace to additionalReadwritePaths: no fix for Bug A
  • git init in workspace: no fix for Bug A
  • Disable anysphere.csharp by renaming extension dir: reduces LS involvement; Bug A remains; Bug B less frequent but still observed
  • Rewrite files with FileStream.SetLength(actual): temporarily repairs Bug B until reinflation

Request

  1. Fix agent StrReplace/Write denial specifically for .cs (or surface a real approval prompt instead of hard deny)
  2. Investigate what component extends EOF by 1024 without writing valid data (Filesync / csharp LS / other)
  3. Ensure agent tools and git see consistent file sizes

Diagnostics available

  • Cursor logs under %APPDATA%\Cursor\logs\...
  • Filesync.log shows uploads/sync of .cs modelVersion
  • Local repro script: fix-cs-filesize.ps1

Steps to Reproduce

SS

Operating System

Windows 10/11

Version Information

For WINDOWS IDE

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Based on what you described, we can narrow this down pretty precisely.

First, the key point: the agent file tools Read/Write/StrReplace don’t have any .cs specific logic, and sandbox.json isn’t related here. The sandbox only controls shell commands, it doesn’t affect the agent edit tools. That’s why insecure_none and additionalReadwritePaths don’t fix this case.

Now the likely cause. The combination of symptoms you listed is very typical and points not to a Cursor setting, but to a filesystem filter driver on the machine itself, like transparent encryption, DLP, or an aggressive antivirus that encrypts by file extension:

  • The on-disk Length is exactly 1024 bytes larger than what File.ReadAllBytes returns. That looks like a fixed encryption header on disk, while reads return decrypted content.
  • git short read while indexing and the realpath error when trying to write are not something you can normally get from user mode on a healthy NTFS volume. That kind of behavior usually comes from a kernel level filter driver.
  • The rest matches too: a new .cs created by Cursor works because it’s still plaintext and hasn’t been picked up by the policy yet. A .cs created by PowerShell can’t be read by Cursor because PowerShell is whitelisted and its output gets encrypted. .md, .txt, .csproj aren’t affected because they’re not in the encryption policy. Cursor doesn’t inflate local files and doesn’t write that header.

How to confirm and fix:

  1. In an admin console, run fltmc filters and look for non Microsoft minifilters.
  2. Run fsutil reparsepoint query C:\path\to\File.cs.
  3. Check what security, encryption, or DLP agents are installed. This is often corporate endpoint software.
  4. Fix: add Cursor.exe and its child node.exe to the whitelist in the encryption or DLP console, or decrypt the project directory, then test again.

I also passed to the team that in this kind of exotic realpath failure, the message Write permission denied is misleading. It’d be better to hint about antivirus or encryption software. Let me know what fltmc filters shows. If there’s a third party filter driver there, this explanation will fit perfectly.