.cursorignore sandbox behavior seems to depend on workspace being a Git repository

Support Help
1

Describe the Bug

I have been testing Cursor’s Sandbox behavior in more detail, especially how .cursorignore affects file access inside the sandbox.

One thing I noticed is that .cursorignore seems to affect sandbox file access only when the workspace contains a Git repository.

In my tests, when the workspace was a Git repository, ignored files were correctly blocked by the sandbox. However, when I repeated similar tests in a workspace without a Git repository, the .cursorignore contents seemed to be ignored completely with respect to sandbox file access.

I am not sure whether this is a documentation gap, expected behavior, or a bug.

Steps to Reproduce

  1. Create a workspace that is not a Git repository.
  2. Add a .cursorignore file.
  3. Add a file that should be excluded from sandbox access, for example:
    secret.txt
  4. Add the file to .cursorignore:
    secret.txt
  5. Ask the agent to read the file from inside the sandbox, for example:
    /shell cat secret.txt
  6. Observe whether the sandbox blocks access to the file.

In my tests, the sandbox did not appear to apply the .cursorignore rules in a workspace without a Git repository.

When I repeated comparable tests in a Git repository, .cursorignore was applied as expected and access to ignored files was denied.

Expected Behavior

I would expect .cursorignore to affect sandbox file access consistently, regardless of whether the workspace is a Git repository.

If .cursorignore is only intended to affect sandboxing inside Git repositories, it would be helpful to document that requirement explicitly.

Operating System

MacOS
Linux

Version Information

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

Additional Information

I’m using a ubuntu based devcontainer on a macbook.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Your observation is correct, and this is currently expected behavior rather than a defect. It also lines up with the git-backed caveat Colin mentioned when you raised this earlier.

There are two separate layers:

  1. Cursor’s built-in tools (file read, edit, grep, list) always honor .cursorignore, whether or not the workspace is a git repo. That’s why the Read tool blocks an ignored file even in a non-git folder.
  2. The sandbox’s filesystem enforcement for terminal commands currently applies .cursorignore only when the workspace is git-backed. In a non-git workspace, a sandboxed cat secret.txt won’t be blocked at the filesystem level.

The git-backed requirement is a performance safeguard. Without a git root to scope the scan, applying .cursorignore to terminal commands can require walking very large or unbounded directory trees (like a home directory), which gets expensive quickly.

For a consistent, sandbox-enforced boundary on terminal commands, run the agent inside a git repository (a plain git init at the workspace root is enough). Your built-in-tool protection applies either way.

You’re right that this isn’t spelled out in the docs today. We’re looking to make the sandbox’s role in .cursorignore enforcement, including this git-backed requirement, clearer there. Thanks for the detailed write-up and repro.

7

Thanks for the clarification — that makes sense.

I fully understand why the sandbox needs a Git-backed workspace to apply .cursorignore safely and efficiently. That requirement is completely legitimate, and it would already help a lot if this caveat were documented clearly.

The more important point for me is the failure mode: if .cursorignore cannot be enforced at the filesystem level because the workspace is not a Git repository, I think sandbox creation should fail with a clear and actionable error message.

Otherwise, the UI/behavior can give users the impression that .cursorignore is protecting terminal commands inside the sandbox, while in reality those commands may still access files that the user explicitly intended to exclude. From a security perspective, that silent fallback feels risky.

So my suggestion would be:

  • Document that sandbox-level .cursorignore enforcement for terminal commands requires a Git-backed workspace.
  • If no Git repository is present, fail sandbox creation instead of silently allowing broader filesystem access.
  • Include a message such as: “Sandbox filesystem enforcement for .cursorignore requires a Git repository. Run git init at the workspace root or adjust your workspace setup.”

That would make the behavior much safer and easier to understand.