Cursor agent keeps editing files I didn't ask it to — I built a small MCP auditor for it

Hey all,

If you’ve been pushing Cursor’s Composer / agent hard on a real codebase, you’ve probably hit this:

You ask it to fix one thing in src/features/auth/login.ts. The diff comes back and — surprise — it also “helpfully” refactored src/utils/helpers.ts, removed an unused import three folders away, or quietly edited a file in /v1/ that has nothing to do with the task.

I’ve been calling this scope creep / wrong-file edits / unrelated-file edits. I kept running into it on my own projects, so a few days ago I packaged what I’d noticed into a small open-source MCP tool: over-reach-detector (v0.0.6, on PyPI + MCP Registry). Sharing here because the Cursor forum already has a bunch of threads on exactly this pattern.

Three patterns that keep coming up

Some I’ve hit myself, others I’ve seen come up over and over on this forum and on r/cursor — one [Dec 2025 bug report] put it perfectly: “Agent makes unauthorized changes because they ‘seem related’.” They mostly fall into three shapes:

1. The “helpful clean-up” on shared utilities

You ask the agent to change one feature file. It follows imports back into a shared util — a “watering hole” file — spots an old syntax pattern, decides to refactor it. That util is depended on by 20 other features. Surprise regression at runtime.

2. Legacy folder misdirection

You ask it to edit UserAvatar.tsx. Retrieval pulls the one in /v1/ or /deprecated/ instead of /src/components/new/. The agent happily edits the wrong file. Your bug is “not fixed” and dead code is now subtly different from prod code.

3. Cascading refactor hallucinations

Agent hits a type error, opens the interface file, “fixes” the type, then feels obligated to update every file that implements that interface. A one-file patch becomes a 20-file architectural diff you never authorized.

Why .cursorrules alone isn’t enough

To be fair, Cursor’s team has officially acknowledged scope creep as a “known limitation of LLM agents” and recommends a real stack of mitigations: Plan mode, Agent Review, explicit rules in .cursor/rules/*.mdc, .cursorignore, and committing before every agent session. That stack is genuinely the right first line of defense and I use most of it daily.

But rules-style guardrails still break under load. The usual reflex is to write stricter language:

  • “Only edit files I explicitly request.”

  • “Don’t touch files outside src/components/.”

  • “Ask before editing unrequested files.”

Once the agent is deep into a long debugging session with a lot of files and prior turns already loaded, its attention is heavily weighted toward solving the immediate error. Negative constraints (“do NOT touch X”) sitting back in the system prompt tend to get noticeably weaker as the conversation grows. If editing a shared util looks like the shortest path to clearing the compile error, the model takes that path and the rule is silently overridden — and you only notice in the diff.

That’s the gap a deterministic audit layer can fill — not as a replacement for Plan mode and .cursor/rules/, but as a second line behind them.

What over-reach-detector does

It’s a small MCP server that compares two things:

  1. Declared scope — the file paths / directories the agent said it would touch (or the boundary you set for the session).

  2. Actual diff — the file paths that actually got modified.

If the agent writes outside the declared scope, the tool surfaces the mismatch with a structured report: which files crept in, where, and the delta between what it said it would do and what it actually did. That’s the whole job — surface the gap before it lands in your git diff and you spend 30 minutes hunting “why did this file even change”.

Minimal example

You tell the agent: “Only touch src/features/auth/.”

Agent runs, ends up writing to:

  • src/features/auth/login.ts :white_check_mark:

  • src/utils/helpers.ts :warning: outside declared scope

  • src/v1/legacy_auth.ts :warning: outside declared scope

The tool flags the last two with a scope-vs-diff report, before you accept the diff.

I’d still use this behind Cursor’s normal safeguards: Plan mode first, Agent Review before accepting changes, explicit .cursor/rules/*.mdc, .cursorignore for critical files, and git/feature branches. This tool is meant as the second line: a quick audit pass after the agent claims it stayed in scope.

How to try it

What I’d love from you

This is v0.0.6 — feedback shapes the next version. Specifically:

  • Which files are your “watering holes”? Which shared / central files does your Cursor agent consistently over-edit without asking?

  • What does your scope-creep horror story look like? The weirder the wrong-file edit, the better.

  • If you wire it into your loop, how does the scope-vs-diff report actually feel in your daily flow?

Horror stories very welcome.

(Full disclosure: I’m the author — first time posting this here.)