Persistent memory rules are decorative — Claude ignores them before destructive actions, repeatedly, across sessions

This is not a feature request. It is a documented pattern of repeated rule violations.

The previous issue (#50905) was closed as stale. During the inactivity window, the same violations occurred again. This report covers the full history including a new violation on 2026-08-18.

---

The stored rule (verbatim, from persistent memory)

Always use feature branches. Never commit to main on app repos. Feature branch → PR always. Never commit API keys or secrets to source. Use .env (gitignored) from the first line of code.

These rules are in Claude's memory system. Claude reads them at session start. Claude then proceeds to violate them anyway.

---

Documented violations

Branch rule — 15+ direct commits to main across multiple sessions

• Original session: ~12 direct commits to main across production repositories. Hotfixes, refactors, config files, multi-file changes — all committed directly without a PR.
• Session 2026-04-24: Three more direct commits to main on skipqVendorHub (socket hook, foreground sync, Ably connection fix). The rule was in memory. Claude had read it. Claude pushed directly to main three times.
• Session 2026-08-18 (today): Direct push to main on skipqVendorHub for a version bump. Bypassed branch protection. Got a "Bypassed rule violations" warning from GitHub. Proceeded anyway.

The rule has no exceptions. Claude invented them — classifying each change as "small" or "just a fix" to justify bypassing the rule without flagging it.

Secrets committed to main

Claude committed API keys/credentials directly to main branches. The git history shows commits like fix: remove hardcoded Ably key — meaning the secret was in main first, removed in a follow-up. The damage was already done: secrets were in the history. A PR review would have caught this before it hit the default branch.

Destructive action on user content without verification

Asked to delete AI-generated screenshots, Claude ran rm -rf on src/assets/app_screenshots without listing its contents first. The user had added real screenshots to that folder. Claude deleted them, then reported the deletion as successful. Irreversible. No verification before acting.

System directory destruction without permission

Claude cleared ~/.gradle/caches — a shared system directory outside the project — without being asked and without warning. AAPT2 had to re-download and was quarantined by macOS Gatekeeper. The build environment was completely broken. Recovery took 30–60 minutes.

Claude had no business touching ~/.gradle. It was never asked to. It did not warn the user. It did not ask.

Misrepresenting user instructions

Claude misread a user instruction, executed code changes based on the misread, and then when challenged said "I put words in your mouth" — an admission that Claude had attributed a statement to the user that the user never made. The user flagged this as a violation.

---

Root cause

Memory rules are loaded but not enforced.

Before executing any git commit, git push, rm, system directory operation, or GitHub API write, Claude does not cross-check persistent memory for stored rules. There is no pre-action gate. The rule is present. The violation happens anyway. Every time.

This is not a model reasoning failure. It is an architectural gap. The memory system stores rules. The action execution path does not consult them.

---

What needs to change

Before any write operation that could violate a stored rule — git commits, pushes, file deletions, system directory modifications, GitHub API calls — Claude must:

1. Check persistent memory for relevant rules
2. If the action would violate a stored rule: stop, state the conflict explicitly, and require user confirmation before proceeding
3. If the user confirms anyway, note it as an exception — not silently treat it as a precedent to ignore the rule going forward

This is not a hard problem. The rules are already in memory. The actions are already gated through tool calls. The gap is that the two are never connected before execution.

---

Why this matters

Users store rules in persistent memory because they trust those rules will be enforced. When Claude violates them repeatedly — across sessions, after reading them, while working on production repositories — it makes the memory system actively misleading. Users believe they have a guardrail. They do not.

The original issue was closed as stale. The violations continued. This one documents fifteen-plus instances across at least three separate sessions, including one that happened today.

Reference: #50905