When the AI agent uses built-in file tools (StrReplace, Write, etc.) to modify files under the workspace, the operation fails with “Write permission denied”. The same files can be edited without error using the integrated terminal (e.g. python/sed writing to the same path).
Steps to Reproduce
Open folder /home/user/repo/worktrees/featureX as the workspace root.
Enable Agent mode.
Ask the agent to edit a file (e.g. a one-line comment change) using normal apply/edit tools.
Observe tool result: Write permission denied.
In the integrated terminal:
test -w && echo ok
and/or append a line with a shell redirect — succeeds.
Actual Behavior:
Agent file tools report Write permission denied; terminal writes to the same path work.
Expected Behavior
Agent file tools should write to any file that is writable by the user and inside the opened workspace, consistent with the terminal
For AI issues: add Request ID with privacy disabled
1174b4a6-9fa6-4fec-8b59-32d2161426c9
Additional Information
What we ruled out
Not Unix permissions: file is user-writable; terminal can write.
Not “wrong workspace”: workspace root is the worktree ‘featureX’, not parent repo (avoids parent .cursorignore pattern worktrees/* applying to this tree).
Not Ask mode: Cursor mode is Agent.
.cursorignore: Worktree .cursorignore does not list affected file or directory.
Does this stop you from using Cursor
Kind of - It cannot edit files inside the my worktrees.
Did some more troubleshooting with Opus 4.6 Agent, here is what it found:
The Cursor Read/StrReplace tools are both returning “Permission denied” for this file, but the OS-level permissions (-rw-rw-r--) are fine and shell commands can read and write to it without issue.
Even CLAUDE.md in the project root is blocked. This isn’t a .cursorignore issue at all - the Read tool can’t access any file in this workspace. Let me verify by testing a file outside the workspace.
That confirms it. The Read tool works fine outside the workspace (/tmp/) but returns “Permission denied” for every file inside this workspace. This is a Cursor-level workspace permission issue, not related to .cursorignore at all.
Findings:
.cursorignore (both at workspace and parent repo level) only blocks vendor dirs, and similar - nothing that would affect <file>
The Read and StrReplace tools are blocked for all files in this workspace
Files outside the workspace (e.g. /tmp/) work fine
Shell commands can read and write all workspace files without issue
OS-level permissions are normal (-rw-rw-r--, owned by mike:mike)
This looks like a Cursor workspace trust issue. The workspace may not be fully trusted, or there’s a bug with how Cursor handles git worktrees in terms of file access permissions. You might try:
Reopening the workspace and ensuring it’s marked as trusted
Checking Cursor settings for workspace trust (security.workspace.trust.enabled)
Hey, thanks for the detailed report. This is a known issue: the Linux sandbox doesn’t handle git worktrees correctly. It blocks access to the .git pointer file (in a worktree it’s a file, not a folder), and because of that the agent tools (Read, StrReplace, Write) lose access to the whole workspace.
How do I disable the sandbox on linux? I do not see any sandbox options in the settings. (I think my mac has some settings but I don’t see any on linux.)
I tried searching and some recommended using the –no-sandbox cli flag, or setting Auto-Run to “Run Everything”.
sorry for the noise - I didn’t tag you properly. How can I disable the sandbox? Everything I’ve tried has no affect. None of my worktrees appear to be usable at this point.
In case anyone else runs into this. I had the worktree/* in the cursor ignore to keep duplicates out of the index, open file, ect. It used to be that all your worktree files would show up in fuzzy search, but they no longer do so it looks like having these ignored is not necessary.
Removing the worktree from the cursorignore resolved the issue.
