cursor agent mode rewrote files you never asked to touch

You enabled cursor agent mode to adjust a button style and came back to diffs in auth middleware, Stripe webhooks, and .env.example.

Agent autonomously searches, edits, and runs commands. That power is the problem. You named one component. It decided login was “related” and rewrote session handling. Cursor Rules sat in settings unread by the model in practice. Composer would have changed twelve lines. Agent changed twelve files and burned premium requests while you reverted half the tree.

Agent changes things nobody asked for

This is the default failure mode when scope is vague.

• Diff includes middleware.ts when you asked about Button.tsx
• Package.json gained dependencies you did not approve
• Stripe or Supabase client files changed during a “spacing fix”
• Tests deleted as “obsolete” without you running them
• Agent ran shell commands you did not preview
• Git status shows twenty files; you expected one

Agent is tuned to complete goals, not to minimize blast radius. “Make the dashboard look better” becomes a redesign plus data layer changes.

Review diffs file by file before accept. If a path was not in your prompt, reject the whole batch. One accepted stray edit teaches the thread that roaming is fine. That habit costs more premium requests than starting over with a Composer tab on the single file you meant.

Rules ignored on the next turn

You pasted a long RULES.md. Agent still edited api/webhooks/stripe.ts.

Why rules fail in cursor agent mode:

1. Too long. Novel-length rules dilute; the model follows the latest user message instead.
2. Too vague. “Be careful with auth” does not beat “only edit files under src/components/dashboard/.”
3. Wrong root. Workspace contains two clones; rules reference paths Agent does not see — see cursor worktree confusion.
4. No rejection habit. You accept bad diffs and the thread learns the wrong pattern.
5. Thread pollution. Earlier turns encouraged refactors; later turns repeat them.

Effective rules are three lines: allowed folder, forbidden folders (auth/, payments/, prisma/), and “minimal diff only.”

Composer vs auth and payment files

Composer with a single @ file rarely roams into webhook secrets. Agent mode goes hunting.

Use Composer when: CSS, copy, component props, localized types, one failing test file with stack trace pasted.

Use Agent only when: you listed explicit paths, you need terminal output, and you will review every file before save.

Never Agent-first on: Stripe routes, OAuth callbacks, RLS policies, production env loaders, database migrations. One wrong line ships silent payment failures. Fix those with manual edits or a surgical Composer session after you read the file.

What cursor agent mode looks like when it runs away

You will notice behavior before you notice billing.

Terminal tabs open without your click. Multiple files show the Agent spinner. Suggested commands include npm install packages you never heard of. The chat summary says “refactored for consistency” when you asked for padding.

Usage drops because each autonomous pass is a premium request with wide context. You pay for the cleanup and the revert.

Why cursor agent mode expands scope

Agent chains tools: search, read, edit, run. Each step uses the model’s guess about what “done” means. Related files score high in search. Auth imports your page; Agent “fixes” auth. Env vars missing in preview; Agent rewrites loader and example secrets together.

AI-built apps from Lovable or Replit arrive with tangled env and auth. Agent sees broken imports everywhere and patches broadly instead of tracing one production misconfig. Fixing deploy settings manually — the five settings pattern on lovable deploy — often costs zero Agent turns versus a roaming session.

Composer versus Agent is also a billing choice. Agent with tools enabled sends more context and triggers more follow-up turns. A CSS padding fix that Composer resolves in one request can become a six-file Agent saga. Default to the cheaper lane until you have a written list of files that must change together.

Tame cursor agent mode — numbered fix path

1. State allowed paths in the first sentence: “Only edit src/components/Header.tsx.”
2. Shorten rules to folder allowlist and forbidden payment/auth paths.
3. Open the correct workspace root — one repo, not a parent with clones.
4. Prefer Composer for single-file tasks; escalate to Agent only with a file list.
5. Preview terminal commands before approve; deny installs you did not request.
6. Reject whole diff if any forbidden path appears; start fresh chat.
7. Run tests yourself after small merges; do not trust Agent “all passing” without output.

cursor agent mode guardrail checklist

• Prompt names one directory or file unless multi-file is explicit
• Rules under ten lines with forbidden paths listed
• Auth, Stripe, Supabase, and migration folders Agent-off by default
• Composer first for UI and copy
• Workspace root is the running app, not a parent of duplicates
• Terminal commands reviewed before execution
• Production env checklist done outside Agent when symptoms are deploy-shaped

cursor agent mode is a power tool, not a safe default for every prompt.

FAQ

Why does cursor agent mode change files I did not mention?

Agent searches the repo for related code and applies multi-file fixes it infers from your goal. Without a tight path and enforced rules, it expands scope to auth, env loaders, and dependencies it thinks are connected.

How do I make cursor agent mode respect Cursor Rules?

Keep rules short — one screen max. State the allowed root folder, forbidden paths like payments and auth unless named, and require minimal diffs. Reject out-of-scope changes in review instead of re-prompting in the same thread.

When should I use Composer instead of cursor agent mode?

Use Composer for single-file UI tweaks, copy changes, and localized type fixes. Use Agent only when you need tool use across files and you have listed exactly which paths may change. Never use Agent for exploratory edits on billing or login code.