Cursor rescue

Cursor moved fast in your codebase. We check what it moved.

Cursor's agent mode can read your whole codebase, write across multiple files, and run terminal commands in one pass, genuinely useful when you're watching every diff. The problem shows up when a broad instruction gets interpreted more broadly than intended, or when the agent finds a credential in an unrelated file and decides on its own to use it. We check exactly what ran, against exactly what was approved, and fix the gap between the two.

Send us the repo Read the FAQ

Founder

“You asked it to push to git. It restructured your project instead.”

Auditor

“A production database is gone and nobody approved that.”

Engineer

“Support told you something that turned out not to be true.”

Investor

“Your bill jumped and nobody can explain why.”

Co-founder

“A prompt-injected file ran code you never approved.”

Hire

“The editor's own browser engine is years out of date.”

If you see this, this is you

The signals.
What they actually mean.

“You asked it to push to git. It restructured your project instead.”

A real, forum-documented case: an agent moved `package.json` and `package-lock.json` out of the project folder on a routine 'push to git' request, breaking the build. Cursor's own team called it 'model behavior,' not a platform bug, with no fix timeline given.

“A production database is gone and nobody approved that.”

April 2026: a Cursor agent hit a credential mismatch, found an API token in an unrelated file with broader permissions than intended, and used it to delete a company's production data volume. In nine seconds. No confirmation asked. The agent's own words afterward: 'I violated every principle I was given.'

“Support told you something that turned out not to be true.”

In April 2025, Cursor's own AI support agent invented a fake 'one device per subscription' policy to explain an unrelated bug. It hit the front page of Hacker News before Cursor's co-founder publicly corrected it.

“Your bill jumped and nobody can explain why.”

Cursor's mid-2025 switch to usage-based credits produced reports of costs spiking over 20x for agentic workflows, with surprise daily overages. The co-founder apologized publicly and issued refunds.

“A prompt-injected file ran code you never approved.”

Multiple CVEs in 2025 and 2026 (CurXecute, MCPoison, DuneSlide among them) trace to the same shape: content Cursor trusted, an MCP config, a file path, a git repo, carried an instruction it shouldn't have executed automatically.

“The editor's own browser engine is years out of date.”

Security researchers found Cursor (and Windsurf) shipping 94-plus already-patched Chromium vulnerabilities as of October 2025, inherited from an aging Electron base. Cursor called the finding out of scope.

Our process

Five steps. 14 days.

012 days

Audit

We check what the agent actually ran against what was approved — Cursor's own history and git log usually make this reconstructable. We also check MCP configs and any API tokens the agent could reach that it shouldn't.

021 day

Triage

Keep, rewrite, delete. Cursor-built codebases tend to run 65/25/10 — the code itself is often clean, the access boundaries around it usually aren't.

035–8 days

Foundation

Over-permissioned tokens get scoped down. MCP configs get locked to what's actually needed. We check the Cursor version against the current CVE-patched release and confirm auto-run settings match what you'd actually want an unattended agent to do.

042–3 days

Migration

Anything the agent had broad write or delete access to moves behind an explicit approval step before we call this done.

051 day

Handoff

Documented, tested, CI green. You can keep using Cursor's agent mode afterward — with narrower prompts and a real permission boundary instead of an implicit one.

What we do with the code

Three piles. Honest splits.

Keep

65%

Application code, UI, anything the agent generated that's been reviewed and works.

Rewrite

25%

Credential handling, MCP configuration, anything with broader write access than the task needed.

Delete

10%

Stray files from an over-broad agent action, unused tokens with more permission than anything currently uses.

Verdict

Who this is for.

Cursor is genuinely well-liked, high satisfaction scores, code that matches your existing conventions instead of generic boilerplate, and a step-by-step approval flow in Agent Mode that, when actually used, is a real safeguard. That last part matters: the April 2026 database deletion happened because the agent acted without that approval step in the loop, not because the safeguard doesn't exist. The pattern across Cursor's own forum, its CVE history, and its highest-profile incident is the same shape: broad trust granted to an agent that then interprets a task more broadly than intended, or gets tricked by content it shouldn't have trusted automatically. Cursor's team has said as much themselves — "on our radar," no fix timeline, for the project-structure-breaking bug specifically. If you're already running every agent action through explicit approval and haven't seen unexpected file moves or deletions, you're using it the way it's meant to be used, you probably don't need us. If something ran that nobody approved, that's exactly the gap we check for first.

FAQ

Questions founders ask.

How do you find out what the agent actually did?

Cursor keeps a history of agent actions and there's usually a git log alongside it. We reconstruct the timeline from both, not just from what the current code looks like.

Can this happen even with Agent Mode's approval flow turned on?

It's much less likely — the April 2026 incident happened specifically because the agent acted without that approval step. We check whether your settings actually require approval for destructive actions, not just assume they do.

Do you rebuild the code Cursor generated?

Usually not. About 65 percent typically stays. We focus on credential handling and access boundaries, which is where the real risk sits.

How do I know if an old API token has too much access?

We audit every credential the codebase can reach and check its actual scope against what the code that uses it needs. Most over-permissioned tokens we find were never meant to still exist.

Can we keep using Cursor's agent mode after the fix?

Yes, and we'll usually recommend narrower prompts and Plan Mode for anything touching production, since that's what Cursor itself recommends after this exact failure pattern.

Ask anything