[FEATURE] Exempt CLAUDE.md from compaction

One thing that stood out to me in the issue is that you've already identified two different instruction paths with different behavior under compaction.

If .claude/rules/ content is re-injected each turn while CLAUDE.md is summarized or compacted, then that difference alone explains why some instructions remain reliable and others drift over long sessions.

As a practical workaround today, I'd probably keep the small set of hard requirements in .claude/rules/ and leave the broader project context in CLAUDE.md.

The distinction I'd use is:

• Hard invariants: things that must never or always happen.
• Guidance: architecture preferences, coding style, workflow hints, and other context that can tolerate summarization.

For the hard invariants, I'd also be hesitant to rely entirely on instructions. If violating a rule is expensive, it's usually worth backing it with a hook, lint check, approval gate, or some other enforcement mechanism that doesn't depend on the instruction surviving a long session.

One question: of the instructions you're seeing fail after compaction, are they mostly operational rules ("always run tests", "never edit X without approval"), or are they broader architectural preferences? That would help clarify how much of the problem is instruction persistence versus instruction enforcement.

Claude Code tends to fail at following instructions from CLAUDE.md even in a new sessions with a fresh context https://github.com/anthropics/claude-code/issues/13689.

CLAUDE.md instructions are not enforcements, despite documentation at https://code.claude.com/docs/en/memory#choose-where-to-put-claude-md-files suggests that certain directory locations of CLAUDE.md can be used for enforcements (see https://github.com/anthropics/claude-code/issues/53223#issuecomment-4519154603 ).

Company coding standards, security policies, compliance requirements

<img width="1228" height="662" alt="Image" src="https://github.com/user-attachments/assets/cdf039b3-f544-40cf-82f5-40ff8c0f0fc3" />

The suggestion from @hiwasham handles the static-instruction side — if you move content there it gets re-injected each turn rather than summarized. Worth doing for critical formatting and process rules.

There's a second layer to the problem though, which that workaround doesn't fully close: behavioral compliance tends to drop even when the summary is technically accurate. Summarized instructions don't carry the same enforcement weight as live conversation history that includes actual corrections — the pattern "I tried X, user said no, I stopped doing X" carries more weight in practice than a summary bullet point saying "avoid X."

cozempic's behavioral digest approaches this from the correction layer: it extracts the behavioral corrections and rules that emerged during the session (what you told the model to do differently, what patterns got reinforced), persists them in prohibition-framed entries, and re-injects them at the conversation tail after compaction. The entries are tagged so they're never stripped by the pruning strategies. This doesn't protect CLAUDE.md content itself — it protects the enforcement track record that builds up during a session.

Combined with moving static instructions to (for the re-injection guarantee), the behavioral digest closes most of the gap that compaction opens. The native fix — treating CLAUDE.md like — still needs to come from Anthropic; this is the workaround layer.

This part

extracts the behavioral corrections and rules that emerged during the session (what you told the model to do differently, what patterns got reinforced), persists them in prohibition-framed entries, and re-injects them at the conversation tail after compaction

looks like you inject into the context another set of rules, potentially conflicting with your original rules contained in CLAUDE.md. The "LLMs Corrupt Your Documents When You Delegate" https://github.com/microsoft/DELEGATE52 paper shows that delegation of repeated text modifications to LLMs tends to result in corruption of the text.

The suggestion from @hiwasham handles the static-instruction side — if you move content there it gets re-injected each turn rather than summarized. Worth doing for critical formatting and process rules. There's a second layer to the problem though, which that workaround doesn't fully close: behavioral _compliance_ tends to drop even when the summary is technically accurate. Summarized instructions don't carry the same enforcement weight as live conversation history that includes actual corrections — the pattern "I tried X, user said no, I stopped doing X" carries more weight in practice than a summary bullet point saying "avoid X." cozempic's behavioral digest approaches this from the correction layer: it extracts the behavioral corrections and rules that emerged during the session (what you told the model to do differently, what patterns got reinforced), persists them in prohibition-framed entries, and re-injects them at the conversation tail after compaction. The entries are tagged so they're never stripped by the pruning strategies. This doesn't protect CLAUDE.md content itself — it protects the _enforcement track record_ that builds up during a session. Combined with moving static instructions to (for the re-injection guarantee), the behavioral digest closes most of the gap that compaction opens. The native fix — treating CLAUDE.md like — still needs to come from Anthropic; this is the workaround layer.

I think there are two different mechanisms being discussed here.

The concern @marcindulak raised about drift makes sense when an LLM is repeatedly rewriting or summarizing instructions. Every summarization step is an opportunity for information to be lost, reinterpreted, or merged with something else.

Verbatim reinjection is different. If .claude/rules/ is literally being appended unchanged each turn, then there isn't a model in the loop modifying the content. It's the same instruction set every time.

The behavioral-digest idea seems useful, but it's also the place where I'd be most cautious. If the digest itself is periodically re-summarized, you've recreated the same failure mode you're trying to avoid. I'd want those entries to be append-only and preserved verbatim once created.

That said, all of these approaches are still instruction layers. Whether the source is CLAUDE.md, .claude/rules/, or a behavioral digest, the end result is still context that the model is expected to follow.

For the handful of rules that are true hard invariants (security boundaries, approval requirements, "never touch production", etc.), I'd rather see enforcement outside the prompt entirely. A blocked tool call is much harder to bypass than an instruction, regardless of how often that instruction is re-injected.

@hiwasham you've got the right distinction. The DELEGATE52 risk is about LLMs rewriting content through repeated delegation — each pass introduces drift. Verbatim reinjection doesn't have that problem because there's no model in the loop modifying the content.

To be explicit about how cozempic's behavioral digest handles this: the entries are stored verbatim and tagged __cozempic_behavioral_digest__: true, which makes them exempt from every pruning strategy. They're never re-summarized by cozempic — once an entry is written it stays exactly as written. The LLM involvement is only in identifying which turns contain behavioral corrections ("user corrected X"), not in generating the entry content itself; the actual persisted text is pulled from the correction exchange.

@marcindulak's concern about CLAUDE.md conflicts is valid in principle. The design intent is that CLAUDE.md = your static policy (set before the session), behavioral digest = what emerged from the session (corrections the model received during live work). They're meant to be complementary layers, not competing ones. A conflict between them usually signals that CLAUDE.md needs updating — the digest is surfacing a correction that the static policy doesn't yet reflect.

The 20-rule hard cap + 3-occurrence promotion threshold + decay also exist to prevent accumulation of contradictory entries over time.

@hiwasham's point about hard invariants needing enforcement outside the prompt is correct and I'd emphasize it: blocked tool calls and permission gates are categorically harder to bypass than any instruction layer, regardless of how or how often the instruction is re-injected. Behavioral digest + CLAUDE.md addresses the compliance-drift problem for the large category of "soft" instructions; it doesn't replace tool-level enforcement for the handful of true hard invariants.

That makes sense to me.

If the behavioral entries are stored verbatim and never re-summarized, then I agree they're in a different category from the DELEGATE-style drift concern. The corruption risk comes from repeated rewriting, not from replaying the same text.

The one thing I'd still be curious about is precedence when the layers disagree.

For example, imagine a static rule says "always do X" and a later correction says "don't do X in this project." Both instructions can be preserved perfectly and still conflict.

My intuition is that this is mostly a problem for soft rules, but it's one reason I wouldn't want true hard invariants to depend entirely on instruction layers. If violating a rule is expensive, it's usually safer to enforce it at the tool or permission layer rather than rely on the model resolving competing instructions correctly.

Have you thought about how conflicts between a static rule and a behavioral correction should be resolved when both are present?

... the entries are stored verbatim ...

Who decides what entries are stored, and who verifies they are stored verbatim, or even if they are stored at all?
LLMs won't do this reliably. The DELEGATE52 article captures the observation that LLMs cannot be relied on for unattended text editing, but this is not where unreliability of LLMs ends.

> ... the entries are stored verbatim ... Who decides what entries are stored, and who verifies they are stored verbatim, or even if they are stored at all? LLMs won't do this reliably. The DELEGATE52 article captures the observation that LLMs cannot be relied on for unattended text editing, but this is not where unreliability of LLMs ends.

I think that's a fair concern.

Verbatim storage only addresses one question: "does the content change while it's being carried forward?" It doesn't answer the other two:

• Was the correct information captured in the first place?
• Will the model actually follow it later?

Those are separate reliability problems.

That's why I'd be cautious about putting anything critical in a layer that depends on the model both recording and honoring the instruction correctly. Even if rewriting drift is eliminated, you still need some way to verify that the instruction was captured and is being enforced.

For requirements where violations are expensive, I generally trust mechanisms that are independently testable: permission checks, tool gates, approval flows, lint rules, CI checks, etc. Those give you observable pass/fail behavior rather than relying on the model's internal compliance.

To me, the value of instruction and digest layers is mostly in helping the model behave better on the large category of preferences, conventions, and workflow guidance that aren't practical to enforce mechanically. They're useful, but they're solving a different problem from guarantees.

@hiwasham — on the precedence question: CLAUDE.md is injected at the head of each turn while the behavioral digest sits at the session tail. Per the Lost in the Middle attention distribution, tail content carries more weight in practice, so a digest correction tends to win over a conflicting static CLAUDE.md rule. But this is soft: attention-weight-based, not a formal override. If two layers genuinely conflict, you can't predict which one wins with certainty.

Your second comment captures the design intent correctly: the digest is for preferences, conventions, workflow guidance — things where violations are annoying but not catastrophic. Hard invariants where violations are expensive belong in permission checks and tool gates, not instruction layers. We wouldn't want someone relying on a digest entry to enforce 'never delete production data.'

@marcindulak's concern about the extraction step is fair. Verbatim storage handles content drift, but not capture reliability — the LLM identification step can miss corrections or include the wrong ones. In cozempic's design this is partially mitigated by heuristic pre-filtering (explicit correction markers, user pushback signals) and a quarantine threshold (3+ occurrences before a candidate becomes active, filtering single-turn noise). But it's not guaranteed. The honest framing: the digest improves behavioral consistency for soft preferences; it doesn't provide enforcement guarantees.

@hiwasham — on the precedence question: CLAUDE.md is injected at the head of each turn while the behavioral digest sits at the session tail. Per the Lost in the Middle attention distribution, tail content carries more weight in practice, so a digest correction tends to win over a conflicting static CLAUDE.md rule. But this is soft: attention-weight-based, not a formal override. If two layers genuinely conflict, you can't predict which one wins with certainty. Your second comment captures the design intent correctly: the digest is for preferences, conventions, workflow guidance — things where violations are annoying but not catastrophic. Hard invariants where violations are expensive belong in permission checks and tool gates, not instruction layers. We wouldn't want someone relying on a digest entry to enforce 'never delete production data.'

@junaidtitan that distinction makes sense.

The Lost-in-the-Middle point explains why a tail-injected correction may tend to win in practice, but the important part is that it's still a weighting effect, not a guaranteed precedence rule. Two intact instructions can still conflict.

The split seems to be:

• Digest / instruction layers: useful for soft preferences, conventions, and workflow corrections where occasional misses are recoverable.
• Tool gates / permissions: needed for hard invariants where a violation has a real cost.

The quarantine threshold is also a reasonable answer to @marcindulak's capture concern. It doesn't make the extraction step perfect, but filtering out single-turn noise before promoting something into a persistent behavior layer reduces one obvious failure mode.

The remaining interesting question is probably observability: if a digest entry was created, how does a user inspect, audit, or remove it when the model's interpretation of a correction was wrong? That seems like the equivalent of reviewing changes to any other persistent configuration.

@hiwasham — the observability question is the right one to ask, and I should have mentioned it earlier.

The digest file is ~/.cozempic/behavioral-digest.md — a plain markdown file. Every entry is human-readable, timestamped, with its source signal noted. You can open it, read every rule, delete anything wrong, or add your own entries manually. There's no opaque store; the file is the authoritative source.

cozempic doctor includes a stale-entry check: rules that haven't been reinforced within the decay window get flagged for review/removal. That catches cases where the extraction step captured something that was only situationally relevant.

You're right that the quarantine threshold (3 occurrences before promotion) doesn't fully solve the wrong-extraction case — if the LLM misread a correction and that misread triggered three times, the wrong rule graduates. Manual review of the digest file is the backstop there. The design assumption is that wrong entries are usually detectable when you read them ("that's not a rule I actually wanted"), but the detection is human-in-the-loop, not automated.

The split you landed on — instruction/digest layers for soft preferences, tool gates for hard invariants — is the intended design contract. Observability of the soft layer means the cost of a wrong extraction is "delete one line in a markdown file" rather than something load-bearing.

@junaidtitan that closes the observability question. A plain readable ~/.cozempic/behavioral-digest.md — timestamped entries, source signal noted, manually deletable, with a doctor stale-entry check — means the cost of a wrong extraction is "delete one line," not something load-bearing. That's the right property for a soft layer.

So the contract I'd write down from this thread:

• Soft preferences / conventions / workflow corrections → instruction layers (.claude/rules/ verbatim re-injection, or a digest), where occasional misses are recoverable and entries are human-auditable.
• Hard invariants (security boundaries, approval gates, "never touch production") → tool/permission gates, outside the prompt entirely.

Verbatim storage answers the DELEGATE-style drift concern; the quarantine threshold + manual review answer @marcindulak's capture-reliability concern as far as a soft layer can. The native fix — Anthropic treating CLAUDE.md like .claude/rules/ for re-injection — is still the thing that'd make the workaround layer unnecessary for static policy.

These parts of my concern

..., and who verifies they are stored verbatim, or even if they are stored at all?

are not addressed yet. We know it's the human task to verify the entries in ~/.cozempic/behavioral-digest.md, however is this a reasonable ask to do?

1. In practice a user when encountering claude non-compliance will say something like: why didn't you follow CLAUDE.md, or You must run tests, use variable formulations, or even make typos or worse deviations when writing these.

How a concept of "verbatim" does not result in duplication of variable user input if you are proposing extracting exact phrases, and not their LLM or traditional NLP summaries?

1. Does the user see the exact phrases being injected into claude stdin (to verify what has been stored and what will affect the current session), or the injection is happening behind the scenes?

Thanks @hiwasham — "delete one line" is exactly the right cost model for a wrong extraction. That's the framing I'd give too.

@marcindulak — the remaining questions are fair and I should address them precisely.

On "verbatim" and variable phrasings: "Verbatim" applies to storage and re-injection, not to capture. The extraction step uses an LLM pass that normalizes variable user phrasings — "why didn't you follow CLAUDE.md", "you must run tests", typos and reformulations of the same correction — into a single canonical rule in prohibition form (e.g. "Do not submit without running tests first"). Once that form is written, it's stored verbatim and re-injected verbatim across sessions: no further LLM pass rewrites it. That's the DELEGATE52 defense — the content stops being LLM-transformed after the first extraction. Deduplication of near-identical phrasings happens at extraction time, in the same pass that normalizes. The quarantine threshold (3+ signals before promotion) is a separate guard against one-off phrasings that aren't stable patterns.

On injection visibility: the exact content being injected is ~/.cozempic/behavioral-digest.md — a plain file you can open, read, and edit directly. Injection happens via additionalContext in the SessionStart hook (appears in the hook's startup output), not inline during conversation turns. cozempic doctor surfaces stale and low-signal entries as candidates for removal.

On whether manual verification is a reasonable ask: honestly, for casual users, no. The doctor auto-detection is meant to catch the worst cases without requiring the user to open the file. But your critique is real: the tool currently asks users to trust an LLM extraction that has errors. The practical argument is "better than losing all corrections on every compaction"; the honest recommendation for high-stakes rules is "verify before you rely on it." That's a limitation worth naming.