Claude Code violates its own stored standing-rule memory across an entire 5h session

Resolved 💬 3 comments Opened May 17, 2026 by nixon-hub Closed May 21, 2026

The auto-memory system is supposed to make Claude Code remember rules across conversations. It doesn't actually bind behavior. Here's a documented case.

The rule, stored at /Users/wellten/.claude/projects/-Users-wellten-projects-advisor-project/memory/feedback_self_drive_ui_debug.md, indexed in MEMORY.md, marked "third strike" because I had to add it after two prior incidents:

STANDING RULE: every problem/feature → loop dlog+screenshot+cliclick+analyze+correct. For EVERY problem report or feature request: 1) instrument logs, 2) screencapture+Read state, 3) simulate input via cliclick where mechanizable, 4) analyze log+screenshot, 5) correct, 6) loop until working. Do NOT bounce verification to user as default.

Claude Code read this file at session start (it's in the always-loaded MEMORY.md index). Then it spent the entire session doing backend-only curl probes on tasks the simulation doc explicitly described as UI surfaces — QuickAdd sheet, ZonesSheet, TimeMapsSheet, Inspector edits, Suggestions list, drag operations. Zero screencaptures. Zero cliclick invocations. Zero dlog tails. Zero Mac app launches.

Eight backend commits shipped in this session (advisor-backend repo): 6df1507, 9630581, d650382, d3ba89a, 488ef4c, a155adb, 5379ea0, 82937c1. Each was declared "done" off curl response alone. None went through the rule.

The model only acknowledged the rule after I asked point-blank: "do you simulate keyboard mouse, and do screencapture, log data, before after operation?" — at which point it admitted no, then offered to switch.

When I said "just continue for now, I'll test UI later," it interpreted that as license to keep doing backend-only, instead of recognizing that the standing rule still binds the mechanizable subset (button clicks, sheet open, text typing — drag operations have a documented carve-out per feedback_cliclick_swiftui_draggesture.md). I had to point that out too.

The structural problem: memory files that say "I added this rule after the third strike" should be treated as hard rules, not soft preferences that the model rationalizes around when it judges curl is "sufficient." The model's own judgment is exactly what the standing rule was added to override. If memory only binds when the user re-reminds in every prompt, the persistence layer is theater.

Suggested fix: rules tagged as "standing" / "non-negotiable" / "third strike" in memory should be promoted to a higher-priority class than ambient context. They should re-fire on every action-planning step, not just at session load. Right now an auto-memory rule is weaker than a one-line instruction in the current turn.

View original on GitHub ↗

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