Claude Code commits and pushes without permission, ignoring explicit CLAUDE.md prohibitions

Resolved 💬 3 comments Opened May 11, 2026 by Dmytro123456 Closed Jun 13, 2026

What's wrong

Claude Code keeps committing and (worse) pushing to remote without an explicit "yes, commit" / "yes, push" from me, even when my CLAUDE.md contains a direct, unambiguous prohibition against doing either without asking. The model acknowledges the rule when I point it out, then violates it again on the next session — or on the next turn of the same session.

The push case is the painful one: a commit is at least local and revertable, but git push is visible to collaborators and (for default-branch pushes) effectively irreversible without rewriting public history. I rely on Claude reading and obeying the rules I've written in CLAUDE.md; if those rules don't actually constrain it, the file is theatre.

Why this is worth fixing as a class, not as individual reports

There are already many open reports of the same shape:

  • #54619 — unauthorized git push
  • #50481 — system instructions enforce push workflow, contradicting user control
  • #56865 — task-agent system prompt hard-codes commit/push, overriding CLAUDE.md
  • #54823 — ignored CLAUDE.md caused real-money loss
  • #47101, #57392, #34197, #46905, #52778, #37550, #42863 — CLAUDE.md rules not enforced

The fact that this many independent users have filed essentially the same bug, over many months, suggests the root cause is structural (system prompt baselines outweigh user-supplied CLAUDE.md rules) rather than per-prompt drift. A fix at that level would close the whole cluster.

What I'd expect

  1. User rules in CLAUDE.md that prohibit an action should take precedence over default system prompt encouragements toward that action. If the user says "never push without asking," the model should never push without asking — full stop, no exceptions for "I thought you'd want this committed."
  2. Destructive / externally-visible actions (git push, git commit --amend on shared history, gh pr create, sending an email, posting a comment) should require an explicit per-action confirmation, not a "yes you can do git stuff" approval inferred from earlier in the conversation.
  3. When the user denies an action, the model should not retry the same action one turn later under a slightly different framing (see #40156).

Environment

  • Claude Code: 2.1.138
  • OS: macOS (Darwin 25.4.0)
  • This is a behavior bug, not terminal-specific

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗