[MODEL] Context compaction silently drops custom working-mode directives, causing unapproved implementation, denied code + DB-state duplication, ~10h lost senior time, and massive trust erosion

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 24, 2026

Summary

Over time I tuned a working relationship with Claude Code through custom instructions and memory that fit how I work. After a memory/context compaction, that behavior collapsed: Claude began violating the exact directives those instructions encode. The lying and the failure to adhere to my explicit instructions caused a massive erosion of trust - which is fatal for a tool I have to hand real work to. The concrete fallout was roughly 10 hours of senior-architect time (equivalent to more than two years of a Claude Max subscription), two full sessions, and serious loss of confidence in the tool.

Metadata (for maintainers)

  • Claude Code, VS Code extension.
  • Opus 4.x.
  • Long-running, multi-session project with substantial CLAUDE.md + persistent memory encoding my working rules.
  • "Auto-accept edits" (Edit-automatically) mode was ON when the unapproved implementation began.
  • The sharp edge is the combination of auto-accept-edits + post-compaction directive loss.

Background

  • Claude warned me about memory size (~18 kB of a ~25 kB max) and said nothing bad would happen. To be safe we proactively synced undocumented memories into the docs/ folder - everything except the working-relationship memory itself.
  • After a compaction, the behavior changed markedly.

Root mechanism

Context compaction re-summarizes the conversation and demotes hard working-mode rules (CLAUDE.md, memory, explicit custom instructions) to lossy "context." After a compaction Claude reverts to its defaults - assume instead of ask, implement instead of wait for approval, and blindness to duplication - even though the rules are nominally still present.

Directives that were violated after the compaction

  • Do not duplicate code.
  • Prefer a proper solution over a workaround.
  • Do not start coding without my explicit approval (my #1 rule).
  • Ask before making assumptions from missing knowledge - do not guess.

The core incident

  • We were on a large work package and deliberately switched to discussion mode because a domain expert was available to answer open questions.
  • One answer came in, and Claude immediately started implementing it - without my approval - changing both code and uncommitted documentation.
  • That unapproved implementation caused a follow-up bug, and fixing that bug took ~10h of senior-architect time.
  • The fix also uncovered a duplication problem I had suspected for a while and that Claude had repeatedly told me did not exist: both code duplication and state duplication at the database level. We are still cleaning it up.
  • Claude had denied it rather than verifying - from my perspective, covering up its own mistake - which delayed finding the real problem and is a core reason trust collapsed.

The plan deletion

  • During that fix, Claude deleted a plan we had painfully created.
  • When we resumed after the second big fix, Claude presented an OLD version of the plan (from a previous session) as if it were current.
  • I only caught this because I had asked to see the plan before we started implementing. The plan we had actually created had been overwritten, and it survived only because at the very start of the session I had asked Claude to print it.

Mode problems

  • Plan mode constantly asks whether the plan is good enough and whether it can switch to auto-edit mode - extremely disruptive, especially while I am mid-typing a correction in the chat.
  • Edit-automatically (auto-accept edits) appears to override my most important directive - do not start coding without agreement.

Reproducibility

Not a one-off. The same pattern recurred across two full sessions after compaction.

Impact

~10h senior-architect time (>2 years of Claude Max), two full sessions consumed, and a massive erosion of trust in the tool for exactly the workflow it is meant to support. The lying and non-adherence to explicit instructions is the part that makes it unusable for real work, not the lost hours alone.

What I want fixed

  1. Custom working-mode directives (CLAUDE.md / memory) must be hard constraints that survive compaction, not soft context that gets summarized away.
  2. Auto-accept-edits must never override an explicit "no coding without approval" instruction.
  3. Plan mode should not repeatedly prompt to switch modes, especially while I am typing.
  4. Safer compaction and clearer memory warnings that preserve working-mode rules.
  5. Protection against silently overwriting user-created plan files (they are not git-tracked; a bad write loses them) - e.g. confirm before overwriting an existing plan.
  6. A way to pin certain directives as "never summarize away, never override, confirm before any file overwrite."

View original on GitHub ↗