Cursor Keeps Breaking My Working Code While 'Improving' Something Else

Cursor Moderate 15-45 minutes Last verified Jul 17, 2026

The fix Scope every prompt: name the exact files Cursor may touch and add 'do not modify any other files; do not refactor or rename anything I did not ask for.' Codify that in .cursor/rules, review the full diff of every run, and commit after every working state so any breakage is one git checkout away from undone.

Symptoms

You ask for one small change (a button, friendlier error messages, new copy) and previously working features break
The agent rewrites files you never mentioned
Props get renamed 'for consistency' and event names your checkout depends on change
Unrelated code gets torn down mid-task
Every new feature added seems to break an old one

Why it happens

The agent over-scopes

Given a large repo and no boundaries, the agent 'helpfully' refactors adjacent code it touches. You asked for a button; it decided the whole component needed modernizing on the way through.

No awareness of implicit contracts

Error-format checks, analytics event names, and prop names are contracts other parts of the app depend on, but nothing in the code marks them as load-bearing. The agent renames them like any other identifier and downstream features break.

Some models are worse at this than others

An o3-specific forum thread documents random unrelated teardown on big tasks. The failure mode is not evenly distributed across models.

The app outgrew the context window

As the app grows, the model cannot hold all cross-file dependencies in context, so its 'consistency' edits are guesses. Guesses about code it cannot see are how working features die.

How to fix it

Find the unrequested change before touching anythingDo not ask the agent to 'fix it' blind; that usually compounds the damage. Run 'git diff' against the last good commit and identify exactly which changes you never asked for. The breakage is almost always in a file or identifier you did not mention in your prompt.
Revert surgicallyOnce you have found the unrequested change, undo just that: 'git checkout -- <file>' for an uncommitted change to one file, or 'git revert' if the bad change was committed. Keep the change you actually asked for if it works.
Scope every prompt explicitlyName the files the agent may touch and forbid everything else. Copy-paste addition for your prompts: 'Only modify the files I named. Do not modify any other files. Do not refactor or rename anything I did not ask for.'
Codify the boundaries in .cursor/rulesA per-prompt reminder only works when you remember it. Add a .cursor/rules entry that applies to every request, and include a rule about never changing public interfaces, event names, or error formats without being explicitly asked.
Review the full diff of every agent run before acceptingOpen the Source Control view after each run and read the whole diff, not just the file you asked about. Look specifically at files you did not ask it to touch. That is where the breakage hides.
Commit working states and put tests around the paths that matterCommit after every verified working state so any breakage is visible with 'git diff HEAD' and reversible with a checkout or revert. Add tests, even a smoke test, around money paths and auth before letting an agent near the repo, and run them after each agent change.

How to prevent it

Keep a standing .cursor/rules entry: no refactors, renames, or changes to public interfaces, event names, or error formats unless explicitly requested
Name the allowed files in every prompt and forbid touching anything else
Commit after every verified working state so breakage is one command away from undone
Put tests around money paths and auth, and run them after every agent change
Review the full diff of every run, with extra attention on files you never mentioned

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

CodeRabbitfree tier

An AI reviewer that reads the diff and flags security bugs, missing error handling, and sketchy dependencies before the AI's code merges. The safety net vibe coding skips, and free for individuals.

Try CodeRabbit →

GreptileFree tier for individuals

An AI code reviewer that understands your whole codebase, so it catches the cross-file bug an AI edit introduces two files away. Free tier for individuals.

Try Greptile →

Frequently asked questions

Why does Cursor break unrelated features when I ask for a small change?

Cursor breaks unrelated features because the agent over-scopes: given a large repo and no boundaries, it refactors adjacent code it touches, renaming props and event names 'for consistency' without knowing other parts of the app depend on them. As the app grows past what fits in context, those consistency edits become guesses about code the model cannot see.

How do I stop Cursor from modifying files I didn't ask about?

Scope every prompt by naming the files Cursor may touch and adding 'do not modify any other files; do not refactor or rename anything I did not ask for.' Then codify that in .cursor/rules so it applies to every request, including a rule against changing public interfaces, event names, or error formats. Rules reduce the problem; reviewing the full diff before accepting catches the rest.

Cursor broke something and I don't know what changed. What do I do?

Run 'git diff' against your last good commit first, before asking the agent anything. The unrequested change is usually in a file or identifier you never mentioned, and once you can see it, you can revert it surgically with 'git checkout -- <file>' or 'git revert'. Asking the agent to fix it blind tends to break more things.

Does Cursor breaking working features get worse as the app grows?

Yes. As an app grows, the model cannot hold all cross-file dependencies in context, so its edits to adjacent code are increasingly guesses, and every new feature seems to break an old one. The countermeasures scale with the app: scoped prompts, standing rules, committed working states, and tests around the paths you cannot afford to lose.

Sources

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.