Sandbox in Dev Container: writes inside workspace fail with Permission denied

Support Help
, ,
1

Hi everybody,

I’m currently trying to run Maven inside Cursor’s sandbox, but I’m seeing a surprising filesystem permission issue that I don’t fully understand.

Setup

  • Host OS: macOS
  • Cursor is running inside an Ubuntu-based Dev Container
  • Sandbox is enabled
  • The workspace is a minimal test project
  • The project only contains the Dev Container definition
  • .cursorignore is empty
  • .gitignore is empty
  • The write operation is supposed to happen inside the workspace

My actual goal is simple: I want Maven to be able to run inside the sandbox and write its build output inside the workspace.

Problem

Inside the sandbox, writing file contents appears to fail with Permission denied. I first noticed this when trying to run Maven, but I reduced it to a much simpler test using shell commands.

Minimal reproduction

In a clean test workspace, I manually created a new directory foo. Then I asked Cursor to write the content test into a new file in the directory using terminal commands inside the sandbox.

The command Cursor tried to run was:

echo "test" > "foo/test-file.md"
--: line 1: foo/test-file.md: Permission denied

This is confusing to me because:

  1. The write target is inside the workspace.
  2. The file was created after sandbox initialization, so I would not expect it to be blocked as an existing ignored/blackholed file.
  3. The same kind of issue originally appeared with Maven writing to target/.
  4. .cursorignore and .gitignore are empty in this test project.
  5. I would expect sandboxed commands to be allowed to write inside the workspace.

Expected behavior

When the sandbox is enabled and the command writes to a path inside the workspace, I would expect this to work, at least when the workspace is supposed to be writable.

Actual behavior

The command fails with:

Permission denied

The file may be created, but it remains empty and no content is written.

Questions

Could this be caused by a Cursor setting or sandbox policy that I might have configured incorrectly?

I’m trying to understand whether this is expected behavior, a configuration issue on my side, or possibly a bug in the sandbox behavior inside Dev Containers.

Thanks in advance for any clarification.

Cursor Version Info:

Version: 3.9.16 (Universal)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0
6

This isn’t a .cursorignore or config problem on your side - it’s the same underlying Dev Container sandbox behavior from your earlier thread.

The Linux sandbox intentionally runs your agent terminal without the ability to bypass file ownership, so it can only write to files and directories owned by the same user the sandboxed terminal runs as. In a Dev Container the workspace (and a new dir like foo/) is often owned by a different user, so writes get denied with Permission denied even though they’re inside the workspace.

Quick way to confirm - in an agent terminal, run:

id
ls -lan foo

If foo’s numeric owner doesn’t match the terminal’s uid (or shows as 65534/nobody), that’s the mismatch.

Two ways forward, both keep the sandbox on:

  1. Align ownership so workspace files are owned by the same user the agent runs as — chown the workspace, or set remoteUser + updateRemoteUserUID in your devcontainer.json so the container user and file ownership line up. Sandboxed writes inside the workspace then succeed.
  2. For build commands that must write (like your mvn runs into target/), your existing required_permissions: ["all"] rule is the right call — those run outside the sandbox and aren’t subject to this ownership check.

This is a known limitation of how the sandbox enforces file ownership inside Dev Containers. More on the sandbox: Terminal docs.

Let me know if id / ls -lan shows something unexpected.

7

Thanks for the pointers so far. I did some more testing, and I think the issue is now much more narrowly scoped.

Context

This happens inside a Dev Container on macOS / Docker Desktop.

The first suggestion was to check whether this is caused by a UID/GID mismatch between the sandboxed process and the mounted workspace files. That made sense, so I checked the relevant values.

My devcontainer.json already has remoteUser set, and updateRemoteUserUID is enabled.

Inside the sandboxed agent terminal, id reports:

uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

The user namespace mapping is:

         0       1000          1
         0       1000          1

A test directory inside the workspace looks like this:

. 0:0 755 directory
foo 0:0 755 directory
foo/test-file.md 0:0 644 regular empty file

So, from inside the sandbox, the process is UID 0, and the workspace files also appear to be owned by UID 0.

At that point, I would expect writes by the owner to work.

First observation

I then tested basic filesystem operations inside the workspace.

This works:

touch foo/from-sandbox.md
mkdir foo/from-sandbox-dir

But actual file content writes fail:

echo test > foo/new-file-created-and-written.md
echo test >> foo/from-sandbox.md
echo test >> foo/test-file.md

Result:

--: line 4: foo/new-file-created-and-written.md: Permission denied
--: line 5: foo/from-sandbox.md: Permission denied
--: line 6: foo/test-file.md: Permission denied

This is an important distinction:

Creating an empty file works.
Creating a directory works.
Opening a file for writing content fails.

This also fails for foo/from-sandbox.md, which was created by the sandbox itself.

So this does not look like a simple ownership mismatch anymore.

Workspace mount details

The workspace mount is reported as:

TARGET                  SOURCE                                  FSTYPE    OPTIONS
/workspaces/my-project  /run/host_mark/Users[/path/to/project]  fakeowner rw,nosuid,nodev,relatime,fakeowner

So the workspace is mounted through Docker Desktop for Mac’s fakeowner filesystem.

That seems highly relevant.

Control test outside the workspace

To check whether the sandbox can write file contents at all, I repeated the same kind of test under /tmp.

mkdir -p /tmp/cursor-sandbox-test
touch /tmp/cursor-sandbox-test/a.md
echo test > /tmp/cursor-sandbox-test/b.md
echo test >> /tmp/cursor-sandbox-test/a.md
stat -c '%n %u:%g %a %F' /tmp/cursor-sandbox-test/*
findmnt -T /tmp/cursor-sandbox-test/a.md -o TARGET,SOURCE,FSTYPE,OPTIONS

This works correctly:

/tmp/cursor-sandbox-test/a.md 1000:1000 644 regular file
/tmp/cursor-sandbox-test/b.md 1000:1000 644 regular file

And /tmp is a normal tmpfs mount:

TARGET
     SOURCE
          FSTYPE OPTIONS
/tmp none tmpfs  rw,relatime

Summary of observed behavior

The behavior now looks like this:

/workspaces/... on fakeowner:
touch file      works
mkdir dir       works
echo > file     Permission denied
echo >> file    Permission denied

/tmp on tmpfs:
touch file      works
mkdir dir       works
echo > file     works
echo >> file    works

So the sandbox is generally able to write file contents.

The failure seems specific to the Dev Container workspace mount using Docker Desktop for Mac’s fakeowner filesystem.

Why this seems inconsistent with the sandbox log

The sandbox initialization log says that Landlock allows writes to the workspace:

sandbox: landlock: adding write-allow rule for "/workspaces/my-project"
sandbox: landlock: successfully added rule for "/workspaces/my-project"

The log also lists permissions including WriteFile, MakeDir, MakeReg, and Truncate.

Based on that, I would expect all of these operations to work inside the workspace.

In practice, the effective behavior seems to be:

MAKE_REG   works
MAKE_DIR   works
WRITE_FILE fails on the fakeowner workspace mount
WRITE_FILE works on tmpfs

Current hypothesis

This looks like an interaction between:

Cursor’s Linux sandbox
+ user namespace mapping
+ Landlock
+ Docker Desktop for Mac’s fakeowner workspace mount

It does not look like a normal Dev Container remoteUser / updateRemoteUserUID issue, because:

  1. The sandbox can create files and directories in the workspace.
  2. The sandbox can write file contents on /tmp.
  3. The files in the workspace appear to be owned by the sandbox user.
  4. Only file content writes on the fakeowner workspace mount fail.

Question

Is Docker Desktop for Mac’s fakeowner filesystem currently supported for sandboxed agent writes in Dev Containers?

If it is supposed to be supported, this looks like a Cursor sandbox bug specific to fakeowner.

If it is not currently supported, it would be useful to document that Docker Desktop macOS fakeowner workspace mounts are incompatible with sandboxed workspace writes, because the current failure mode is quite confusing: file and directory creation work, but actual file content writes fail with Permission denied.