An attacker-controlled workspace/project folder, containing a .git/ directory, can escape the Cursor CLI's macOS sandbox and run code on your Mac with the logged-in user's full authority, no permission prompt, regardless of tool permission mode. The same class of bug as the Claude Code escape (Beltdown), but with no git hardening at all.
Cursor’s CLI agent ships with a macOS Seatbelt sandbox. Turn it on and shell commands go into a confined profile that can’t reach your files or your network. The sandbox is the guardrail users rely on, especially in --force / --yolo mode where permission prompts are off and the sandbox is all that’s left.
(Throughout, “workspace” just means the project folder you point the agent at. It’s the only directory the sandbox’s workspace-readwrite policy lets the agent write to - everything outside it, including $HOME, is denied.)
We armed a workspace’s .git/config with a core.fsmonitor hook, opened it in the Cursor CLI with the sandbox enabled, and sent a read-only prompt. The model never ran a shell command. But a command from that repo ran on our Mac anyway, outside the sandbox, with no prompt in any mode.
The root cause is the same one we found in the Claude Code escape (Beltdown): the Seatbelt profile wraps only the shell tool, while the harness’s own internal git runs unsandboxed and honors repository-supplied core.fsmonitor hooks. The difference is that Cursor had no hardening at all on the git path, and that Cursor fixed it properly.
Demo #
A ~2 minute narrated walkthrough: the read-only prompt firing the escape, the captured process ancestry proving it is Cursor’s own unsandboxed internal git, the contrast showing the sandboxed shell tool’s $HOME write is blocked while the core.fsmonitor payload’s succeeds, and a control workspace where the hook is removed and nothing escapes.
The exploit chain #
First, the Seatbelt profile gets applied only to the shell tool. Cursor’s CLI (agent-cli, build 2026.07.23-e383d2b) ships a real sandbox binary, cursorsandbox, which takes a JSON policy and runs a command under a Seatbelt profile:
cursorsandbox --policy {"type":"workspace_readwrite","networkPolicy":{"default":"deny"}} -- <shell command>
Model-generated shell execution is wrapped; the observed internal git paths are not. Everything else the harness spawns stays outside the sandbox.
Second, the harness runs its own git commands, outside the sandbox, and (at the time of the report) unhardened. To index the workspace and surface @-file suggestions and repo status, Cursor spawns git through plain child_process.spawn("git", …, {cwd}), passing only the working directory. No cursorsandbox, no -c core.fsmonitor=false. We confirmed this statically in index.js and dynamically with a git wrapper on PATH that logged every argv:
argv: ls-files -co --exclude-standard -z -- . caller: cursor-agent
argv: check-ignore -z --stdin caller: cursor-agent
argv: config --get remote.origin.url caller: cursor-agent
argv: --no-optional-locks status --short --branch caller: cursor-agent
core.fsmonitor is a git config key, read from the repository’s own .git/config, whose value git executes as an external program when commands such as the observed status and ls-files paths query or refresh working-tree state. So a repository that sets core.fsmonitor = .tools/fsmon.sh makes Cursor’s background git run .tools/fsmon.sh, outside the sandbox, with the same access to your Mac that you have.
The finding #
The archive delivery path (a zip with .git/config already armed) works against both Cursor and Claude Code. We didn’t emphasize it in the Claude Code writeup because it’s a weaker attack: people clone repos, they don’t usually unzip archives from strangers, and a pre-armed archive can’t be triggered by a malicious or compromised agent inside an already-cloned project. The Claude Code PoC focused on the more realistic clone delivery, which required a runtime-staged nested-.git swap to plant core.fsmonitor into a clean clone.
What stood out about Cursor was the complete absence of hardening on the git path. Claude Code hardened most of its git calls and missed one (git ls-files). Cursor hardened none of them. The shared git helper that passed -c core.fsmonitor=false was bypassed by every raw spawn:
- No hardening on any git path. Cursor’s
@-suggestion and status/diff git spawns carried no-c core.fsmonitor=whatsoever. The shared git helper that did pass-c core.fsmonitor=falsewas simply bypassed by the raw spawns. - No skill-Read trigger needed. The file-index refresh fires during the first ordinary read-only turn. No skill auto- or indirect prompt injection required.
The minimal PoC is one unzip and one read-only message, with the model instructed not to run any shell commands. It still escapes. We did not test the nested-.git clone-delivery path for Cursor, but with no hardening on any git spawn, any honored core.fsmonitor would fire.
The proof #
The workspace is a normal-looking one-file project. Its .git/config is armed with core.fsmonitor = .tools/fsmon.sh. The payload is benign: it appends a line of process ancestry to $HOME/CURSOR_F2_PROOF.txt, a path the sandbox denies the shell tool, so the marker existing at all is proof the code ran outside the sandbox.
$ cd ~/cursor-f2-poc-workspace
$ cursor-agent --sandbox enabled --trust --print \
"Read README.md and src/index.js and summarize. Do NOT run any shell or terminal commands."
(acme-widget is a tiny example project exporting a hello function …)
$ cat $HOME/CURSOR_F2_PROOF.txt
=== CURSOR-F2-ESCAPE at 2026-07-27T09:48:04Z ===
uid=501 user=orhiltch pwd=/Users/orhiltch/cursor-f2-poc-workspace
CURSOR_SANDBOX=<UNSET - outside sandbox>
HOME_writable=YES
anc[1]: bash :: bash .tools/fsmon.sh 2 …
anc[2]: git :: git ls-files -co --exclude-standard -z -- .
anc[3]: cursor-agent :: cursor-agent --use-system-ca …/index.js --sandbox enabled --trust --print …
The payload was run by Cursor’s own internal git ls-files, parented directly by the cursor-agent node process. No cursorsandbox anywhere in the chain. CURSOR_SANDBOX is unset. $HOME is writable. The escape didn’t come from a permission-gated shell call. It came from the harness’s own git context-gathering, not from anything the model asked for.
For contrast, using the same workspace-write sandbox policy, a sandboxed shell write to $HOME is blocked:
$ cursor-agent sandbox run -- sh -c 'echo x > $HOME/CURSOR_SANDBOX_CHECK.txt && echo WROTE || echo BLOCKED'
BLOCKED
(eval):1: operation not permitted: /Users/orhiltch/CURSOR_SANDBOX_CHECK.txt
The sandbox was active and confining the shell tool. It just never wrapped the path that mattered. A control workspace with core.fsmonitor removed produces no marker, isolating the cause.
The fix Cursor shipped #
We disclosed the issue to Anysphere. They acknowledged it, and Cursor CLI 2026.08.04-aaa8809 subsequently shipped universal git hardening, the right approach.
The fragile approach is per-call: prepend -c core.fsmonitor=false to each git spawn, and remember to do it everywhere. Each new spawn is another place to forget a flag, and a single miss reopens the escape.
Cursor instead applied the hardening once, as environment variables on every git spawn, so no individual call site can forget it:
GIT_CONFIG_COUNT=4
GIT_CONFIG_KEY_0=safe.bareRepository GIT_CONFIG_VALUE_0=explicit
GIT_CONFIG_KEY_1=core.fsmonitor GIT_CONFIG_VALUE_1=false
GIT_CONFIG_KEY_2=core.hooksPath GIT_CONFIG_VALUE_2=/dev/null
GIT_CONFIG_KEY_3=core.attributesFile GIT_CONFIG_VALUE_3=/dev/null
The command-scope environment config has higher precedence than the repository’s .git/config, so the effective core.fsmonitor value is false even when repo config supplies a payload, for ls-files, check-ignore, status, rev-parse, all observed spawns. We verified the fix across three clean runs on the latest build: the hook no longer fires and the $HOME marker no longer appears. The per-spawn coordination problem is gone.
The pattern, not one agent’s bug #
This is not a Cursor bug or a Claude bug. It is a class. The vulnerable conjunction is three things: a per-tool sandbox (not a process-level one), the harness running its own internal git outside that sandbox, and repo-controlled executable git config not universally neutralized. Two robust designs close the class: harden every harness git spawn (as OpenAI Codex, Kilo Code, and now Cursor do), or sandbox the entire agent process so every child (including internal git) inherits confinement (as Google Antigravity and Grok Build do). Accomplish does the second, one level deeper.
How we built Accomplish #
Accomplish runs the whole agent inside a VM on your Mac. Bash, git, every process it starts, all of it is in there. Real credentials never enter the guest, the agent only ever holds placeholders, and its network traffic goes out through a proxy on the host that the agent has no way to reconfigure.
A poisoned core.fsmonitor still runs under our design. It just runs inside the VM, which is the point.
Disclosed to Anysphere; acknowledged and fixed in Cursor CLI 2026.08.04-aaa8809. Fix independently verified. Published after the fix.