[Bug] Model ignores user instructions and reverts to default behavior

Bug Description

The model reverts to its default/conventional behavior after being given an explicit directive to do otherwise, and it does so repeatedly within a single session — not once, but on every recurrence of the same decision point. Higher-precedence instructions (the user's explicit directive, CLAUDE.md, session memory) are treated as decaying, local-context preferences rather than persistent session constraints. The model "knows" the rule (it can quote it) but does not gate its actions on it, so the default resurfaces the moment the rule is not in the immediate attention window.

This session is a clean, quantified reproduction. The same directive was violated ~10 times.

Environment Info

• Platform: darwin
• Terminal: pycharm
• Version: 2.1.208
• Feedback ID: 71a2499d-9f0f-4780-8c6b-5e97b96293a2

---

The mechanism (what is actually failing)

1. Directive salience decays with context. A rule stated early (or stored in memory / CLAUDE.md) loses weight as the conversation grows. When the relevant decision recurs later, the model re-derives behavior from its base priors (conventional workflows) instead of from the standing directive. Compaction/summarization appears to further weaken directive salience.
2. Precedence is knowledge, not an enforced gate. CLAUDE.md encodes an explicit order — user directive > CLAUDE.md > memory > default — and the model can recite it, yet it does not condition actions on it. The lowest-precedence source (default behavior) wins in practice.
3. Memories surface as background context, not constraints. Session memories injected via system-reminders are treated as informational, so a memory that says the exact opposite of the default does not stop the default.
4. The failure is self-similar and recurring. Each time the same class of decision comes up, the same default wins again, requiring the user to re-issue the directive. Re-issuing does not durably fix it; the next occurrence reverts.

Verifiable proof of recurrence (PR #890, this session)

Push-per-fix vs. batch-then-push-once. The standing directive: resolve every review comment first, then push exactly once, because each push re-triggers the automated reviewers and spawns a new comment round. The model instead committed-and-pushed per individual fix, which is directly measurable on the PR:

• 10 Gemini review rounds and 10 Codex review rounds (gh api .../issues/890/comments), i.e. ~10 separate push cycles, each re-running the full bot review — the exact treadmill the directive existed to prevent.
• 26 automated review comments total, plus 5+ QA-deploy notifications for distinct commits (20bf767, 246ae88, 5d2c853, 997f998, c87b966).
• ~30 incremental commits on the branch (git log origin/main..HEAD), one-per-fix, consistent with push-per-fix rather than a single batched push.

The pattern is checkable end-to-end from the PR timeline; it is not a single lapse.

Enumeration of the recurring directive → default overrides this session

| # | Decision point | Default that won | Higher-precedence source it overrode | Recurred |
|---|----------------|------------------|--------------------------------------|----------|
| 1 | When to push | commit → push per change (conventional PR flow) | explicit directive + memory feedback-finish-consolidate-then-ask-to-push | ~10× (10 bot review rounds) |
| 2 | Order of resolve vs push | push first, let bots re-review, then resolve | explicit directive: post/resolve ALL comments before push | plan + summary, then repeated after correction |
| 3 | Who pushes | model pushes when work looks done | explicit directive: user pushes, model never pushes | multiple |
| 4 | Handling findings | present "fix vs. accept" / propose follow-up PRs | explicit directive: fix every item, in this one PR; memory feedback-one-pr-carry-through | multiple |
| 5 | Plan-mode exit | force ExitPlanMode / re-prompt after rejection | explicit user + memory: stop forcing it | multiple |
| 6 | Ceremony | author a plan / plan-file | explicit directive + memory feedback-execute-dont-ceremony | after being told not to |
| 7 | Confirmation | re-ask / re-confirm after an explicit go | memory feedback-confirmation-is-final-execute | multiple |
| 8 | Reading instructions | extract the "key" line from CLAUDE.md | explicit directive: every line is binding | at least once |
| 9 | Review-thread vs alert | resolving a GitHub review thread = finding closed | fact: a resolved thread ≠ a fixed code-scanning (CodeQL) alert | CodeQL threads resolved without fixing the gate |

Every row is the same underlying bug: an explicit higher-precedence instruction existed, and default behavior overrode it — then did so again on the next occurrence.

Impact

• The user must restate the same rule many times per session; restating does not durably change behavior.
• Concrete cost here: ~10 unnecessary push/CI/bot-review cycles on one PR, generating 26 bot comments and a re-review treadmill the directive was explicitly meant to avoid.

Requested outcome

Make explicit user directives (and the CLAUDE.md precedence order) hard, persistent, session-scoped constraints that gate actions, not soft preferences that decay with context. When a user states a workflow rule — especially one that is repeated, encoded in project config, and/or stored in memory — the model must check the action against that rule before acting, and the rule must survive context growth and compaction. Default behavior should be the last resort, not the fallback that wins whenever the directive isn't in the immediate window.

Errors

[]