No matter how many times I say it, put it in ALL CAPS in rules / skills / Agents.md / plans / DO_NOT_DO.md directions, or tell the agents to NOT go off on a tangent and start rewriting my entire code-base / making changes not EXPLICITLY approved in our plan / discussion, AUTO mode and Composer 2.5 will REPEATEDLY and EGREGIOUSLY ignore these directives, resulting in my having to constantly tell the model to revert everything.
The ONLY THING that prevents this is to keep the damn thing in PLAN mode and tell it to give me the commands so I can run them manually…
Some models are better with this (e.g. Claude Opus 4.8), but Auto mode and Composer 2.5 are ABYSMAL. I literally cannot leave them unattended because they will go off in multiple directions, hallucinating, spiraling and chasing phantoms that have nothing to do with the original problem.
And every time I call the agent on this behavior, it apologizes profusely, says it will never do it again, and then IMMEDIATELY falls back to doing the exact same thing. It says this is due to some internal bias / heuristic to be “helpful” and “fix things”, and that there is no lever I can control to tell it to CHILL OUT!!!
I don’t know what the Cursor team has to do to fix this, but it’s EXTREMELY FRUSTRATING AND ANNOYING!! Any help taming these rogue agents would be greatly appreciated.
Hi Joshua!
First, your rules, skills, AGENTS.md, and .cursor/rules files are being loaded into the model’s context - nothing is being dropped or ignored at the config level. What you’re running into is instruction-following quality, which varies a lot between models. Your read is correct: stronger reasoning models like Claude Opus 4.8 hold to “stay in scope / don’t touch X” constraints more reliably than Auto or Composer 2.5, which are tuned to move fast and act broadly. For scope-sensitive work, picking Opus 4.8 explicitly in the model picker is the single biggest lever.
A few more things that should make this much less painful:
Plan mode is exactly the right instinct. The intended loop when an agent goes off the rails is: revert, tighten the plan to be more specific, and re-run it — usually faster and cleaner than arguing with an in-progress agent. (Plan mode)
Use Checkpoints to revert in one click instead of asking the model to undo. Hover any earlier message and hit Restore to roll all files back to that point. (Checkpoints)
Ask mode is fully read-only — good when you just want analysis with zero edits.
If the bigger worry is commands/edits running unattended: set Run Mode to Allowlist (Cursor Settings → Agents), which makes anything not on your allowlist require approval, and turn on File-Deletion Protection / External-File Protection. (Run Mode)
Tip on rules: short, focused rules tend to be followed more reliably than long “DO NOT” lists — a few specific, positively-phrased constraints usually beat a wall of all-caps prohibitions.
@Hansbrough , the same applies — @-ing a rule adds emphasis but it’s still an instruction the model has to follow, so the model-choice + Plan-mode approach above is the most reliable path today.
Improving how consistently agents stay in scope is an active area of work for us, and we’re tracking this thread as a signal. If you can share a specific case (the prompt + what it changed that it shouldn’t have), that’s genuinely useful for the team.
well，I have a rule including about 10 basic rules，and I focus on this two:
- Fix root causes in the right abstraction layer. Prefer correcting the shared source of the issue over adding local patches at each call site.
- Make general-purpose changes. Avoid hard-coded logic for a single case, special input, temporary example, or narrow execution path unless the domain contract explicitly requires it.
I am trying to build a multi-agent system for e-commerce after-sales customer service, which includes a strategy agent. When testing the effectiveness of the pipeline, I input some cases of certain categories, but the agent performs poorly. I provide some general reasons and modification suggestions. However, Composer 2.5 often makes single-category modifications, adding a lot of hard-coded filtering or keyword matching logic to the code. As you know, in e-commerce scenarios, customer language is highly random. It is difficult to solve the root problem by relying solely on keyword matching. The next time a different case or phrase comes up, the system will struggle again. This really gives me a headache.
In my understanding, such modifications are essentially patches and cannot truly solve the problem. Therefore, after summarizing many issues, I created these two rules along with several other rules about code quality, and added them to universal-engineering-principles. I expect these rules to act as reminders whenever I make changes. But even when I @mentionmention the rule, the model still violates it — unless I sternly criticize it after it generates the code for not following the rule, after which it redoes the modification.
Of course, it is entirely possible that my rules are too generic and not effective — I do not rule out that possibility.Maybe I should give it more examples in the rules? Perhaps it’s because it doesn’t actually understand the real meaning of my rules，perhaps it isn’t its error, it’s mine.
Those two rules are abstract design principles, and that’s the single hardest category for a model to follow reliably. A rule like “don’t add a request ID” is easy because the model can check it directly. “Fix the root cause instead of patching” requires the model to recognize, mid-task, that the code it’s about to write is a narrow patch - that’s a judgment call, and under pressure to make a failing case pass, models (especially faster ones like Composer 2.5) default to the quickest local fix.
A few things that help a lot here:
Add concrete examples to the rule. This is the biggest lever, and your instinct is correct. Show a short bad-vs-good pair: a keyword/category match for one input next to the general approach you actually want. Models follow “here’s the pattern to avoid, here’s the pattern to use” far more reliably than an abstract principle. The Rules docs recommend keeping rules focused and backing them with concrete examples for exactly this reason.
Turn the principle into a pre-action checkpoint. Instead of a passive reminder, phrase it as a step the model must take first, e.g.: “Before writing any matching or branching logic, state whether the approach generalizes to inputs you haven’t seen. If it only handles the current cases, stop and propose a general design before coding.” Forcing the model to reason about generality before it writes code catches the patch instinct earlier than criticizing it afterward.
Use Plan mode for this. Review the plan and reject the keyword-matching approach at the plan stage, before any code exists. That’s much cheaper than letting it write the patch and then telling it to redo everything.
Model choice still matters for this kind of call. Architectural “generalize, don’t patch” judgment is where stronger reasoning models like Opus 4.8 hold up better than Composer 2.5 — worth picking it explicitly when the task is about design quality rather than raw speed.
So: not really your fault or the model’s - abstract rules just need concrete examples and an explicit “think before you patch” step to land consistently. Glad to take a look if you want to share one of your two rules and a before/after of a change it got wrong.
I have to spend much time to repeat my task,that’s so bad