Cursor's command-line coding agent has a workspace trust feature. It's supposed to stop the agent from acting on a project until you've told it you trust that project. Security researcher Francisco Rosales at Manifold Security found a way around it, and the gap ran deeper than a single missed check.
The setup script that ran before trust was asked
The issue lives in Cursor CLI's worktree feature. Run the CLI with -w, and it creates a worktree under ~/.cursor/worktrees//. A repository can define a setup command for that worktree in a file called .cursor/worktrees.json, using a setup-worktree key. Cursor passes that command straight to sh -c.
That's a normal convenience feature. The problem is when it runs. On builds before 2026.07.23-e383d2b, the setup script executed during workspace resolution, and that step finished before the code path that shows the trust dialog. So a repository's own command ran on your machine before you'd ever seen, let alone answered, the trust prompt.
Rosales put it plainly: the trust gate exists so a user can assert they trust a workspace before the agent acts in it. Code execution is supposed to sit behind that gate. This didn't.
The sandbox didn't cover it either
Cursor CLI also ships a sandbox that limits what terminal commands can read, write, and reach on the network. Reasonable users would assume turning it on protects them here. It doesn't.
The worktree setup script is pinned to insecure_none, the setting that turns the sandbox off entirely for that script. So even a developer running Cursor with --sandbox enabled still had a repository-supplied command execute directly on the host, outside any sandbox boundary.
And once that command runs, Rosales confirmed it has the same access as the person running Cursor. Same files, same credentials, same environment. There's no reduced-privilege step in between.
No advisory, and a bumpy disclosure process
Cursor shipped a fix in build 2026.07.23-e383d2b. What it didn't ship was a security advisory. Rosales said Manifold's report was closed as "Informative" on July 29, with two reasons given: the issue requires a user to clone or open an attacker-controlled repository, and the report didn't demonstrate a bypass of workspace trust in the strictest sense. Manifold pushed back with more context, including a reference to a previous Cursor CVE covering similar territory, and hadn't heard back as of this writing.
It's worth sitting with that first reason for a second. "Requires the user to clone an attacker-controlled repo" describes most of what developers do all day. Cloning repos, opening PRs, checking out a coworker's branch, trying out an open-source tool. That's the entire threat surface AI coding agents operate in.
Not just a Cursor problem
Rosales was careful to scope his team's research to Cursor CLI's worktree mechanism specifically, since that's what they tested and can confirm. But he also flagged that workspace trust bypasses through configuration files or other planted repo content, potentially leading to remote code execution, are a known category. Multiple researchers have found variations of it across different agentic coding tools.
His read on why this keeps happening: speed. Everyone building and shipping with AI coding assistants is optimizing for moving fast, and auditing the configuration a repository ships for a specific agent isn't something most developers are doing. It's not on anyone's checklist yet.
What to actually do about it
The narrow fix: update to build 2026.07.23-e383d2b or later, where the worktree setup script is now gated behind the trust prompt. But Rosales flagged an important caveat — once you click "trust," the script still runs, and it still runs outside the sandbox. Trusting a repo means the code in that script executes on your machine, full stop. If you're opening a repo you haven't fully audited, pass --skip-worktree-setup to skip that step.
The wider takeaway is less comfortable. Rosales doesn't think the trust prompt should be treated as a security control. He called it closer to a warning, and pointed out that many coding assistants already ship modes that skip these dialogs entirely for the sake of speed.
That's the real shift developers and security teams need to make. AI agents are capable, configurable, and genuinely useful for moving faster. They're also a new and significant part of the threat model, and "ask before acting" assumes a pace of development that agentic tooling has already outrun in places.
Why this habit is so easy to miss
Most developers don't think of cloning a repo as an action with consequences. It's step one, not a decision point. You pull down a project, open it, and start reading code before you've formed any opinion about whether you trust it. AI coding agents insert themselves right at that moment, and they're built to act fast on your behalf.
That's exactly the gap this research exposes. A .cursor/worktrees.json file sitting quietly in a repo isn't something most people check for, and there's no reason they would have, until now. It's a small, easy-to-miss configuration detail that happens to sit directly in the path of code execution.
If you're pulling down unfamiliar repos regularly, and most developers are, it's worth treating any agent-specific config file the same way you'd treat a postinstall script in a package.json: something to glance at before you run anything, not after. Worth checking what your agent of choice actually gates, and when.