Headless agent -p ignores sandbox.json and generates helper policy with disableTmpWrite:false

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

On Linux, headless Cursor CLI appears to ignore both project-level and user-level sandbox.json.

I have:

• project file: .cursor/sandbox.json
• user file: ~/.cursor/sandbox.json
Both contain:

  "type": "workspace_readwrite",
  "additionalReadwritePaths": [],
  "additionalReadonlyPaths": [],
  "disableTmpWrite": true,
  "enableSharedBuildCache": false,
  "networkPolicy": {
    "default": "deny",
    "allow": [
      "<server-hostname>"
    ]
  }
}

However, during a real headless run, the policy passed to cursorsandbox is:

{"sandbox":{"type":"workspace_readwrite","cwd":"<project-workspace>","additionalReadwritePaths":[],"networkAccess":false,"disableTmpWrite":false}}

So headless CLI is generating its own sandbox policy and not honoring the sandbox.json values.

Steps to Reproduce

  1. Create .cursor/sandbox.json with disableTmpWrite: true
  2. Run headless agent from that workspace, for example:
agent -p "Use the shell tool to run: touch /tmp/headless-sandbox-probe && echo TOUCH_OK || echo TOUCH_FAIL. Then reply exactly with DONE." \
  --workspace /path/to/workspace \
  --model composer-2 \
  --approve-mcps \
  --trust \
  --sandbox enabled \
  --output-format stream-json \
  --stream-partial-output
  1. Observe that headless sandbox behavior does not reflect the configured sandbox.json
  2. If you capture the helper policy passed to cursorsandbox, it shows disableTmpWrite:false

Expected Behavior

If sandbox.json is supported in headless CLI, the generated helper policy should reflect it, including:

disableTmpWrite: true
enableSharedBuildCache: false
networkPolicy

Operating System

Linux

Version Information

OS: Ubuntu Linux (24.04)
Kernel: 6.8.0-88-generic
Cursor Agent version: 2026.04.08-a41fba1

Does this stop you from using Cursor

Yes. CLI is a core feature for the team currently.

6

Hey! I tried reproducing this on Ubuntu 24.04 with the same agent version (2026.04.08). In my testing, disableTmpWrite: true from .cursor/sandbox.json was actually being honored. /tmp writes get blocked with the config present and allowed without it.

Could you try this exact test and share your results?

Setup — create two workspaces, one with sandbox.json and one without:

mkdir -p /tmp/sandbox-repro/.cursor /tmp/no-sandbox-workspace

cat > /tmp/sandbox-repro/.cursor/sandbox.json << 'EOF'
{
  "type": "workspace_readwrite",
  "disableTmpWrite": true,
  "networkPolicy": { "default": "deny", "allow": [] }
}
EOF

rm -f /tmp/headless-probe-*

Test 1 — WITH sandbox.json (should FAIL to touch /tmp):

agent -p "Use the shell tool to run: touch /tmp/headless-probe-with && echo TOUCH_OK || echo TOUCH_FAIL. Then reply exactly with DONE." \
  --workspace /tmp/sandbox-repro --model composer-2 --approve-mcps --trust \
  --sandbox enabled --output-format stream-json --stream-partial-output

Test 2 — WITHOUT sandbox.json (should succeed):

agent -p "Use the shell tool to run: touch /tmp/headless-probe-without && echo TOUCH_OK || echo TOUCH_FAIL. Then reply exactly with DONE." \
  --workspace /tmp/no-sandbox-workspace --model composer-2 --approve-mcps --trust \
  --sandbox enabled --output-format stream-json --stream-partial-output

Check results:

ls /tmp/headless-probe-with 2>&1
ls /tmp/headless-probe-without 2>&1

If headless-probe-with does NOT exist but headless-probe-without DOES, that means your sandbox.json was respected for temp writes.

7

I tried the repro steps after the new patch, on:

$ agent --version
2026.04.13-a9d7fb5

I was able to narrow this down and get it working locally.

What I found:

  • agent sandbox run ... works
  • direct cursorsandbox --preflight-only works
  • but headless agent -p --sandbox enabled ... was still failing with:
    Sandbox mode is enabled but not available on this system

So this does not seem to be an AppArmor/kernel issue anymore on my machine. It looks like a CLI/headless-path bug.

From tracing the installed CLI bundle, the problem appears to be:

  • the sandbox support check can get cached as false too early
  • and the headless CLI path then keeps using that stale result
  • there is also a sandbox gate in the CLI bundle involved in this path

After patching the local CLI bundle, both of these started working:

  • agent sandbox enable
  • agent -p --sandbox enabled ...

I also re-ran the workspace test from above and confirmed:

  • with .cursor/sandbox.json containing disableTmpWrite: true, /tmp writes are blocked
  • without that file, /tmp writes succeed

So sandbox.json does get honored once the headless sandbox path is actually working.

This looks like an upstream bug in the Cursor CLI headless sandbox initialization / support-check path, not just a local machine configuration issue.

9

Thanks for the thorough investigation! This actually matches a known bug we’re tracking.

Sandbox availability is gated behind a feature flag. The CLI caches the flag evaluation locally with a 24-hour TTL. When that cache expires (e.g. first launch after idle, or a fresh install), the client marks itself as “initialized” but has no evaluation data.

Our team is aware and I’ve added your case to that report!

1 Like