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

Support Help
, ,
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.