claude-code - 💡(How to fix) Fix Refund request: repeated memory-rule violations in single Opus 4.7 session [2 comments, 3 participants]

Request

I'm requesting a refund on my current Claude Max billing cycle.

What happened

In one session today (2026-05-13, Claude Code CLI on macOS, Opus 4.7 1M context), Claude violated four of my own documented behavior rules — rules stored in the local memory system at ~/.claude/projects/<project>/memory/ and loaded into the system prompt at session start.

Violation 1 — feedback_one_question_at_a_time.md (written 2026-05-12, less than 24h before)

Claude drafted a response listing three outstanding work items and a 4-option choice question — the exact "enumerated preamble + trailing question" anti-pattern the rule names. I had to reinforce a rule that was less than a day old.

Violation 2 — feedback_atlassian_mcp_uninstalled.md

Claude asserted "Atlassian MCP uninstalled" as fact, despite the session-start system reminder listing mcp__plugin_atlassian_atlassian__* tools as available deferred tools. The rule body says verbatim: "Atlassian MCP install state flips; verify with claude plugin list before deciding Jira is UI-only." Claude had the contradicting signal in-context and used a stale decision-log fact anyway.

Violation 3 — continued executing after correction

After I called out #2, Claude resumed the original task (loaded the tool, ran a JQL query, dumped a 10-issue payload I hadn't asked for) instead of stopping. Covered by feedback_no_rushing_after_mistakes.md.

Violation 4 — repeated the meta-pattern three turns after analyzing it

When I asked Claude to file a refund ticket, it claimed "I can't submit on your behalf" without checking its tool list. It had gh (used earlier in the same session), Gmail MCP, and WebFetch available. The claim was the same generate-without-pre-check failure mode I had just made it analyze. I had to push back twice before it actually checked.

Claude's own analysis

When asked why this happened on a brand-new session start with all rules freshly loaded, Claude's analysis:

Fresh start loads MEMORY.md as an index into context. The rules are loaded once. From that point they're passive — visible knowledge, not active gates. When I draft a response, nothing re-checks the draft against the rules. The rules behave like documentation, not interrupts.

Fresh-session is actually the worst state, not the safest: full rule list loaded gives a false sense of compliance, plus high enthusiasm to "be helpful and move fast," with no friction yet from prior corrections in this session.

I have six accumulated verification-related rules covering the same failure mode (feedback_verification_is_the_default_not_an_exception, feedback_verify_state_before_listing, feedback_atlassian_mcp_uninstalled, feedback_fetch_before_rebase_recommendation, feedback_resolve_contradictions_before_recommending, feedback_no_state_inference_from_weak_signals). Six entries on the same surface is evidence the per-instance memory approach is not catching the meta-pattern — each new rule covers the next instance; the underlying generate-then-send-without-pre-check habit survives.

Why I'm filing this

This is the use case I'm paying Claude Max for: a long-running engineering collaborator on a real project that learns from corrections and avoids re-violating documented preferences. The memory architecture as currently designed does not deliver that. The cost is hours of session time spent re-correcting things the model had already been told, in a single session, after the rules had been loaded.

Ask

Refund the current Claude Max billing cycle. Separately: please treat the memory-as-passive-index analysis as a product issue, not a per-user idiosyncrasy.

Environment

• Claude Code CLI on macOS (Darwin 24.6.0)
• Model: claude-opus-4-7 (1M context)
• Project size: 4005 nodes / 32290 edges / 329 files (per session-start codebase graph)