I am asking agent to commit changes after the implementation, but I noticed that Agent sometimes ignores this my rule. After the conversation “why” he told me that tooling rules take precedence over my rules.
Steps to Reproduce
Unknown.
Expected Behavior
My rules should take precedence over tooling rules.
Operating System
MacOS
Version Information
Can not copy, I have image in my buffer, which I will post in the next message. This form does not support image inserting ((
One important point: the agent’s explanation about session/runtime rules having higher priority is a model hallucination. The agent made up a plausible reason for why it didn’t follow your rule. In reality, there isn’t a strict priority hierarchy where tooling rules override yours.
Also, the built-in instruction <committing-changes-with-git> you see in the screenshot says the same thing as your rule: NEVER commit changes unless the user explicitly asks you to. So both instructions match, but the model can still break them. That’s a core limitation of LLMs, since they aren’t deterministic.
To reliably block git commands, I recommend using enforcement hooks. They block commands at the system level before execution. A detailed setup example with .cursor/hooks.json is in this thread Curser ignored a rule - #5 by mohitjain.
This also helps:
Write rules in a positive way with a reason Always ask for user approval before any git operation, because… instead of just don’t commit
Keep chats short, since in long sessions the model loses constraints more often
The team is aware of the issue with unreliable rule following. Let me know if hooks help.
What the model showed in the screenshot is its paraphrase of Cursor’s built-in instructions (the built-in system prompt). These instructions are automatically loaded for each agent and include basic safety rules for git operations.
One key point: the built-in rules say “don’t commit without an explicit user request.” Your rule says “commit after each implementation step.” These don’t conflict. You’re explicitly requesting commits, so the model should do them.
The problem is that the model doesn’t always correctly interpret whether your rule counts as an “explicit request.” This is the same non-determinism issue in LLMs I mentioned earlier.
A couple tips:
The workaround “prioritize the user’s rules over other rules” might help, but it’s not guaranteed. The model might ignore it too. It’s better to rephrase the rule more specifically, for example: “After completing each implementation step, immediately run git add and git commit with a descriptive message. This is an explicit user instruction to commit. Don’t ask for confirmation.”
You shouldn’t ask the model to “show session rules.” It can’t accurately reproduce the system prompt, it can only hallucinate something close. What it showed is a paraphrase, not the exact rules.
Let me know if anything changes after you rephrase the rule.