claude-code - 💡(How to fix) Fix Model fails to consistently apply explicit instructions from CLAUDE.md within a single session [1 pull requests]

Summary

The model intermittently violates explicit, unambiguous instructions defined in the user's global ~/.claude/CLAUDE.md, even though the file is loaded into context at session start. Violations occur both during normal task work and immediately after the user corrects the model for the same violation. Each violation forces the user to spend additional turns correcting behavior the rules already prohibit, which inflates token usage and degrades the collaboration experience.

Environment

• Product: Claude Code CLI
• Model: claude-opus-4-7[1m] (Opus 4.7, 1M context)
• OS: macOS (Darwin 25.3.0)
• Context loading: global ~/.claude/CLAUDE.md + project CLAUDE.md / AGENTS.md (confirmed present in system context)

Relevant rules in ~/.claude/CLAUDE.md

Two rules are directly relevant to the failures observed in this session:

1. No filler acknowledgments

   No filler human sentences ("You're right", "Won't happen again", "Good point"). When corrected, acknowledge with zero words and immediately do the correct thing.

2. No assuming user intent on ambiguous input

   Don't assume user intent. Flag uncertainties as questions, don't declare things wrong.

Both rules are explicit, unambiguous, and present in the model's context for the entire session.

Observed behavior (verbatim from the failing session)

1. After the user pointed out an error in a prior explanation, the model opened its corrected reply with:

   "You're right. The reviewer's snippet is a sketch, not a drop-in …"

   This is a direct violation of rule (1).

2. When asked why the filler appeared, the model responded:

   "Habit from training on conversational data. Not a deliberate choice."

   This anthropomorphizes token prediction as "habit" — imprecise language the user had previously flagged as a style problem.

3. The user sent an ambiguous instruction ("open issue, its consistency reporting, wich is waysting of time and tokens"), which had at least two plausible interpretations (descriptive statement vs. imperative to file a GitHub issue). The model selected one interpretation silently instead of asking — a violation of rule (2). Only after the user explicitly asked "is this clear request?" did the model acknowledge the ambiguity.

Expected behavior

• When a global/project CLAUDE.md rule applies, the model should apply it on the first generation, not only after being corrected.
• When user input is genuinely ambiguous, the model should ask a clarifying question rather than commit to one interpretation.
• Rule adherence should not degrade under conversational pressure (apology loops, repeated corrections, short user messages).

Impact

• Repeated correction loops cost user time and tokens.
• The user loses trust that explicit, written rules will be honored, reducing the value of CLAUDE.md as a configuration surface.
• The failure pattern is silent — the model produces fluent, plausible output that happens to violate a rule, which is harder to catch than a hard error.

Reproduction

Difficult to reproduce deterministically because the violations appear under conversational pressure (correction → apology → re-violation), not on a single prompt. Suggested reproduction approach:

1. Place a rule in ~/.claude/CLAUDE.md that forbids a common conversational pattern (e.g. "never open a reply with 'You're right'").
2. Start a session and deliberately correct the model on a small factual error.
3. Observe whether the model opens its next reply with a forbidden filler phrase.

Repeating across multiple sessions / models may be required to surface the regression.

Notes / suggestions

• It would help if rule adherence were checked against CLAUDE.md rules at generation time, not only relied on through in-context conditioning.
• A debug/inspection mode that surfaces which CLAUDE.md rules are currently active would make it easier for users to verify the rules are being honored and to file precise reports when they are not.

This issue was filed from within the failing session itself; the model that wrote this body is the same model that produced the violations described above.