Hey, thanks for the report.
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.