You let Cursor's Agent mode loose on a feature, it touched twelve files across three directories, and now something that was working yesterday has stopped. Or your build passes but production throws a runtime error about a function that does not exist. Or three months of daily prompting has left you with a codebase nobody, including you, fully understands anymore.
Cursor breaks differently from browser-based tools like Bolt or Lovable. It edits your real local files directly, which means the breaks are real too. But it also means you have something those tools often lack: a git history that tells you exactly what changed and when. Here is how to read what went wrong, what you can safely undo yourself, and when the accumulated drift is deep enough that a proper audit is the faster path.
Why Cursor breaks differently from other AI tools
Bolt and Lovable run inside sandboxed browser environments. They have their own deployment pipelines and their own constraints. Cursor is different: it is a code editor sitting on top of your actual repository, editing your actual files, against your actual running services. That is both its power and its specific failure mode.
Agent mode, in particular, is designed to plan and execute multi-step edits across many files in a single session. The model works with a context window that grows as the session progresses, and like every AI model, its accuracy degrades as that context fills. An Agent session that starts clean and focused tends to produce good work. One that runs for three hours across dozens of files tends to produce edits that are locally correct but globally inconsistent: the type it imports from one file does not match the type exported by another, the database query assumes a column that was renamed two sessions ago, the test expects behaviour that the refactor changed.
The other thing Cursor does not do automatically is commit. Browser tools push to their own deployment after every generation. Cursor edits your working directory and leaves the git decisions to you. This means long Agent sessions can accumulate as a single giant uncommitted diff, invisible in version history, and at risk of being wiped by any careless git checkout ..
Diagnose it: six symptoms, six causes
Find your symptom in the left column. The middle column is what is almost always happening underneath it. The right column tells you honestly whether you can fix it without help.
| Symptom | What it usually means | Can you fix it yourself? |
|---|---|---|
| App throws errors after an Agent session that touched many files | Agent's context ran out mid-session. It completed edits in each file individually but lost track of how the pieces connected across files. Type mismatches, missing exports, and silent logic conflicts are typical. | Often, if you have git. Run git diff HEAD~1 to see exactly what changed in the last commit. Narrowing the problem to a specific file makes it fixable. |
| Runtime error about a function or method that does not exist | Agent hallucinated an API call. It referenced a method that does not exist in the library version you are running, or invented a function name that sounds like something the library should have but does not. | Yes. Search the error message, find the call in your code, check the library's actual documentation for what exists, and replace the hallucinated call with the real one. |
| Something stopped working but you do not know what changed | Hours of Agent work accumulated without commits. The working tree diverged from the last known-good state, but there is no record of the intermediate steps. | Yes, with difficulty. git diff shows the full uncommitted diff. If it is large, this is a lesson in committing after each Agent session. Start by reverting the most recent large changes. |
A .env file or API key appeared in a git commit |
Agent added or restructured files without checking that .env is excluded in .gitignore, or generated a new secrets file in a location that is not excluded. |
Partially. You can remove the file from git history with git filter-repo or BFG. But the key is already compromised the moment it was pushed to a remote. Rotate it immediately, before removing it from history. |
| Logic is duplicated across multiple files and both versions are now active | Agent solved the same problem twice in different places, or partially refactored something and left the old version running alongside the new one. Both are being called, and they conflict. | Sometimes. If the duplication is in a single feature area, you can trace the call paths and remove one version. If it is across the whole codebase, you need to understand the full data flow before touching it. |
| App builds but behaves differently in production than locally | Secrets or configuration values in your local .env were never added to your deployment platform. Your local app runs against real services; your deployed app is missing the connection strings to reach them. |
Yes. Open your deployment dashboard (Vercel, Railway, Render, or similar), compare the environment variables section against your local .env, and add anything that is missing. |
The two-hour rule
If you have been in the same Agent session for more than two hours on the same problem, close it and start fresh. You are compounding, not converging.
Cursor's Agent mode works within a session context window. Early in a session, the model has full visibility of what it has done. As the session grows, earlier steps get compressed into summaries. The model continues to work confidently, but it is now editing files with a partial view of the decisions it made at the start of the session. The result is edits that fix what the model can currently see while silently undoing constraints it set up earlier.
Starting a fresh Agent session with a narrower, more specific prompt consistently outperforms continuing an exhausted session. Scope the task to one file or one concern. Let it finish. Commit. Then open the next session.
The five-minute triage you can do yourself right now
Before you pay anyone, run these five checks. They use tools you already have, they cost nothing, and they tell you exactly how serious the situation is.
- Check what is uncommitted. Run
git statusin the project directory. If you see a large list of modified files with no recent commits, that is your immediate problem: hours of Agent work with no checkpoint. Do not rungit checkout .yet. First take stock of what is there. - Check what the last few sessions actually changed. Run
git log --oneline -10to see the recent commit history, thengit show --stat HEADto see which files the most recent commit touched. If one commit changed thirty files, that session's diff is where to start looking. - Verify your .gitignore excludes .env. Run
cat .gitignore | grep -i env. If nothing appears, rungit log --all --full-history -- .envimmediately to check whether the file was ever committed. If it was, treat every secret in it as already compromised and rotate those keys now, before fixing anything else. - Roll back to the last known-good commit and test. Find a commit from before the problem with
git log, rungit stashon your uncommitted changes, thengit checkout <commit-hash>to test that the issue actually started in a specific session. This tells you the blast radius before you start fixing. - Match your local .env against your deployment environment. Open your deployment dashboard and compare it against your local
.envline by line. Anything present locally but absent in production is a likely source of "works on my machine" failures.
If checks one through three came back clean, you are likely dealing with an isolated Agent context problem in a specific session. If check three found secrets in git history, that is urgent and the order of operations is not optional: rotate keys first, then fix the codebase.
When git revert is not enough
A git revert or git reset is the right move when the problem lives in one session's changes. It is not the right move when the problem is in the architecture that months of prompting built. These are the situations where reverting leaves you back at a codebase that was already broken in ways you did not fully see:
- Authentication grafted on rather than designed in. Auth added as an afterthought tends to protect some routes and miss others, with no consistent pattern an audit can validate quickly.
- Database queries that bypass Row Level Security. Cursor can query Supabase directly from frontend code. Without RLS policies, any user who finds the query endpoint gets all the data.
- Dependency drift. Three months of "upgrade this package when it breaks" leaves a codebase with mixed major versions, deprecated APIs still in use, and security advisories that nobody reviewed.
- No tests, no CI. Without a test suite, every Agent session is a trust exercise. Without CI, the only environment where "it works" has ever been verified is your laptop.
If any of these apply, you are in rescue territory rather than patch territory. Read our vibe code rescue service page for how we approach it. Built with a different tool? The same patterns apply to Bolt and Lovable apps.
What a rescue actually costs
Honest numbers. Across the global market, specialist rescue work on Cursor-built apps that need to reach production typically lands somewhere in the USD 2,500 to 7,000 range for a standard project. Cursor apps tend to sit at the higher end of that range compared to Bolt or Lovable projects, because they have usually been developed for longer before the problem is acknowledged, and longer development means more accumulated drift to map and untangle.
What actually moves the cost is the state of the codebase when you arrive. No test suite means the audit starts from zero with no safety net. Secrets in git history mean a rotation exercise across every connected service before the code work begins. No CI means every change after the rescue goes out on faith.
The cheap alternative is a generalist freelancer who will patch the immediate error without understanding the architecture underneath. Cursor projects in particular tend to look locally coherent but be structurally inconsistent, and patching without understanding the full picture typically creates the next problem while fixing the current one.
What a professional rescue actually does
The order matters. Building features on a broken foundation breaks the features. A proper rescue runs in this sequence:
- Full codebase audit first. Read the entire repository before touching anything. Map the auth model, the data access patterns, the dependency tree, and the deployment pipeline. The findings go into a fixed-scope report so you know exactly what is broken before you commit to the work.
- Secrets rotated and moved to the correct layer. Any key that belongs server-side is moved server-side. Any key that was committed to git history is rotated and scrubbed.
- Row Level Security and server-side auth. Data policies written for your actual schema, not assumed. Authentication enforced at the server and database layer, not just the frontend route guard.
- Dependency audit and update. Every package reviewed for active security advisories, major version mismatches addressed in a controlled upgrade rather than letting the next Agent session handle it.
- Version control hygiene and CI. A test suite that covers your critical paths, and a CI pipeline that runs it on every push. From this point, Agent sessions can no longer silently break things that were working.
- Staged deployment. A preview environment that mirrors production. "Works on my machine" stops being the only verification available.
- Then your feature list. Deliberately last. On ground that can hold it.
This is the approach we take on our vibe code rescue service, which covers apps built with Cursor, Bolt, Lovable, v0, and similar tools. If you built with a browser-based tool instead of an IDE, read the Bolt rescue guide for the same structure applied to that deployment model.
Frequently asked questions
Can Cursor Agent mode fix its own broken code?
Sometimes, for isolated bugs. But Agent mode works within a session context that gets compressed as the conversation grows. By the time you have been working for hours, the model is making edits with a compressed view of what happened earlier in the same session. This is why complex multi-step Agent sessions reliably produce the fixes-one-thing-breaks-another pattern. If you have been in the same Agent session for more than two hours on the same problem, starting a fresh session with a narrower scope will serve you better than continuing.
Should I revert to a working commit or keep patching with Cursor?
Revert, if you have a commit where everything worked. This is Cursor's real advantage over browser-based tools like Bolt or Lovable: you have git history. Run git log to find the last green commit, check it out to verify it works, then branch from there and redo the work with a narrower scope per session. Continuing to patch on top of a broken state compounds the problem at the cost of more context per iteration.
Does Cursor Agent mode commit my changes to git automatically?
No. Cursor edits files but does not run git commands unless you explicitly ask it to. The risk is the opposite of what most people expect: hours of Agent work can accumulate as uncommitted local changes that are one git checkout . away from being permanently lost. Commit after each meaningful Agent session, not just when you remember to. Treat each session like a unit of work with a beginning, a commit, and an end.
When do I need a professional rescue versus just using git revert?
A git revert is the right move when the problem is in one session's changes. A professional rescue is the right move when the problem is months of accumulated drift: dependencies that crept past major versions, authentication that was grafted on rather than designed in, database queries that bypass Row Level Security policies, or an architecture that has been patched so many times that nobody fully understands how the pieces connect. Git shows you the history; a rescue fixes what the history built.