Clarification request: How does .cursorignore interact with Auto-Run in Sandbox inside a Dev Container?

Support Help
, , , ,
1

Hi Cursor team,

I’m currently trying to better understand how .cursorignore interacts with Auto-Run in Sandbox, especially when Cursor is running inside a Dev Container.

My setup is Cursor running in an Ubuntu-based Dev Container on a macOS host system. Auto-Run in Sandbox is enabled, and the workspace contains a .cursorignore file.

My expectation so far was that .cursorignore mainly prevents Cursor’s internal tools from reading, indexing, or adding ignored files to context. Based on my understanding of the available documentation, I did not expect .cursorignore to also affect terminal commands executed inside the sandbox — for example cat , git diff , Maven, or other tooling inside the Dev Container — as long as the underlying filesystem permissions would normally allow access.

However, I’m observing different behavior.

When a file is listed in .cursorignore, terminal access by the agent appears to fail. For example, commands such as cat <file> or git diff <file> fail with a permission error. The agent then reports that the file appears to be owned by root and has mode 000, so nobody can read it. When I remove the same file from .cursorignore, the agent can access it again via terminal commands and also via Cursor’s internal tools, as expected.

So it looks like .cursorignore may currently influence the sandboxed filesystem view, not only Cursor’s indexing/context/file-read tools.

I could not find clear documentation for this behavior. The .cursorignore documentation describes which files Cursor should ignore, while the terminal/sandbox documentation describes filesystem and network restrictions, but I couldn’t find an explicit statement about whether .cursorignore is intentionally enforced for sandboxed terminal commands as well.

One additional observation that adds to my confusion: I vaguely remember that Maven commands used to run automatically in sandbox mode in the past. However, I can now observe that Maven commands are blocked and require manual approval before they are executed. I’m not sure whether my memory is wrong, whether this depends on some configuration, or whether Cursor’s behavior has changed recently. If this is intentional, it would be helpful to understand how the decision is made: which commands are auto-run in sandbox mode, which commands still require manual approval, and whether tools such as Maven are treated differently because they may perform network access, filesystem writes, process execution, or other side effects.

Could you clarify the intended behavior here?

In particular, I would like to understand:

  1. Is it expected that files listed in .cursorignore become inaccessible to terminal commands executed by the agent in Auto-Run in Sandbox mode?
  2. Is this behavior considered a stable security boundary that users can rely on?
  3. Does this apply consistently to all tooling launched by the agent inside the Dev Container, for example cat, grep, git diff, build tools, test tools, language servers, scripts, etc.?
  4. Are there known exceptions or limitations where a tool executed by the agent may still be able to access .cursorignore files?
  5. Is the observed root ownership / 000 permission behavior part of the intended implementation, or just an implementation detail?
  6. Is this behavior different when Cursor runs inside a Dev Container compared to running directly on the host?
  7. Under which conditions does a command still require manual approval even when Auto-Run in Sandbox is enabled?
  8. Are any tools , like Maven, Gradle, npm, etc., handled specially by the sandbox or permission system?

The reason I’m asking is that we are evaluating Cursor in a more security-conscious development setup. We would like to understand whether .cursorignore can be part of a security concept together with Auto-Run in Sandbox, or whether it should only be treated as a context/indexing control and not as a reliable filesystem access boundary.

Any clarification or pointer to documentation would be very helpful.

Thanks a lot!

9

Hey @Der_Simon!

On .cursorignore and sandbox filesystem access:

Yes, when Auto-Run in Sandbox is enabled, files listed in .cursorignore are made inaccessible to terminal commands executed by the agent inside the sandbox. This is intentional.

On Linux (including Dev Containers), the sandbox enforces .cursorignore patterns using bind mounts inside a mount namespace. Files matching those patterns get a zero-permission “blackhole” file mounted over them, which is why you see mode 000 and root ownership. Any process inside the sandbox (cat, git diff, Maven, anything) hits the same restricted filesystem view.

On macOS, enforcement works differently: Apple Seatbelt rules deny reads at the syscall level. stat still shows normal file metadata, but access fails with “Operation not permitted.”

There is no Dev Container-specific code path. The sandbox uses the same Linux code whether you’re in a container or on a bare host.

On whether this is a security boundary:

There are two enforcement layers:

  1. Cursor’s built-in agent tools (file read, write, edit, grep, list directory) always check .cursorignore regardless of sandbox mode. This blocks the agent from reading or writing ignored files through its own tools.
  2. The sandbox filesystem layer enforces .cursorignore for shell commands when the command runs inside the sandbox.

Both layers also prevent the agent from modifying .cursorignore itself, so the agent cannot weaken its own restrictions.

For a security-conscious setup, .cursorignore combined with sandbox mode provides meaningful protection. One caveat: the sandbox only enforces the ignore mapping for git-backed workspaces. Non-git directories skip the recursive .cursorignore scan.

On command approval:

In “Auto-Run in Sandbox” mode, a command auto-runs if the sandbox policy covers its requested permissions, or if it matches an entry in your shell allowlist. If neither is true, you get prompted. There is no special treatment for Maven, Gradle, npm, or any other tool. All commands go through the same evaluation.

If Maven commands now prompt when they previously auto-ran, the most likely explanations are:

  • Your approval mode is set to allowlist and mvn is not on your shell allowlist. Adding it would restore auto-run (outside the sandbox).
  • Maven runs but fails inside the sandbox because network access is restricted to allowed domains. Adding the relevant Maven repository domains to your network allowlist in .cursor/sandbox.json would fix that.

These are two separate things: the approval prompt decides whether the command runs at all, while the sandbox network policy decides whether it can reach the network once running.

More details on sandbox setup: sandbox.json Reference | Cursor Docs