For some reason, somebody changed the highest precedent agent rules to disallow automatic git commits. This (in my opinion) was an idiotic change because git is literally intended for tracking file changes with descriptions, and serves as the best “memory” you could ask for, rather than maintaining ARCHITECTURE.md or leaving tons of untracked, unstaged changes in the codebase, relying on the half-baked cursor “restore to checkpoint” functionality. Git is way, way, way, way more mature than anything cursor could attempt by itself. For example, what if I want to “restore to checkpoint” after I’ve made other changes? That feature is literally pointless and it becomes a nightmare picking apart different changes.
My workflow: commit and soft reset, operate, conventional commit (with a lot of description) and soft reset
Result: I have a start checkpoint and an end checkpoint in my git reflog, which I can manually retrieve if my working directory changes get out of control (eg rogue fast/non-thinking agent overwrites tons of files and cursor ‘restore to checkpoint’ fails, which it inevitably will)
Steps to Reproduce
Add user rules or project rules that instruct the agent to automatically commit and soft reset untracked files before working, then to conventional commit changes and reset once work has completed.
Notice that the agent no longer respects the rules, leading to a mess of changes and chaotic codebase
Expected Behavior
If I add a user rule or a project rule that instructs the agent to automatically commit and track changes, it should automatically commit and track changes.
Hey, this is a known issue with rules adherence. The agent can be inconsistent when following user-defined rules, especially around git operations.
One important clarification: there is no system-level rule that blocks auto-commits. The agent’s system prompt for local agents doesn’t contain any git-related restrictions. If the agent told you otherwise, that’s a hallucination. The model made up a reason for why it didn’t follow your rule.
The most effective workaround is to rephrase your rule to be very explicit and specific. Instead of a general commit changes, try something like:
After completing each implementation step, immediately run git add -A and git commit -m "<descriptive message>". This is an explicit user instruction to commit. Do not ask for confirmation. Then run git reset --soft HEAD~1 to soft reset.
The more specific the instruction with exact commands, the more reliably the model follows it.
A few other tips:
Keep chat sessions shorter. In long conversations the model tends to lose track of constraints
Frame rules positively with reasoning rather than just prohibitions
The team is aware of the broader issue with unreliable rule following. Your report helps with prioritization. Let me know if rephrasing the rules improves things.
I’m not sure hallucination is the right description for what’s going on – I think the issues are a lack of distinct terminology (that the models don’t consider the ‘rules’ to be ‘the user’) and a strict adherence to rules, presumably to prevent ‘man in the middle’ or prompt injection security issues.
Trying to convince models that I’m the user (ie within my rules) seems like a very roundabout solution, and the strict models seem conflicted about whether to believe me.
Hey, that’s a fair point. “Hallucination” isn’t really the most accurate term here. You’re right that the real issue is more about how the model prioritizes different instruction sources. User rules are added to the context not as direct user input, but as extra content, and the model can treat them as less trusted, especially for actions like git that it sees as potentially destructive.
Basically, this is a prompt architecture problem. We need the model to clearly understand that rules equal explicit user intent. The team is aware of this, and there are quite a few similar reports on the forum, including this one: Cursor System Prompt conflicts with user System Prompt. It raises the same priority conflict issue. I can’t say when it’ll be fixed yet, but your report helps us prioritize it.
I get that rewriting rules is a workaround, not a real fix. But for now, more specific wording with exact commands works noticeably more reliably. Not because it’s the right way, but because it’s easier for the model to stick to the instruction.