File change system-reminders inject full file contents repeatedly, context grows to 692K tokens

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/16021
2. https://github.com/anthropics/claude-code/issues/4464
3. https://github.com/anthropics/claude-code/issues/27599

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Update: I've upgraded to 2.1.92 and ran a baseline test. On a fresh session with no file edits, the first assistant message consumed 20,209 cache_creation tokens — but that appears to be system prompt + tool definitions + skills/memory, not file change notifications.

The original report was about within-session accumulation after file edits. I haven't reproduced that on 2.1.92 yet.

Reproduction prompt for others: Paste this as your first message in a new session to check your baseline, then again after editing 10+ files over 20+ turns:

Run this command and show me the raw output:

LATEST=$(ls -t ~/.claude/projects/*/*.jsonl 2>/dev/null | head -1)
python3 -c "
import json, sys
msgs = []
with open('$LATEST') as f:
    for line in f:
        d = json.loads(line)
        if d.get('type') == 'assistant' and 'usage' in d.get('message', {}):
            msgs.append(d['message']['usage'])

if not msgs:
    print('No assistant messages found')
else:
    first = msgs[0]
    last = msgs[-1]
    print(f'Messages: {len(msgs)}')
    print(f'First msg — input: {first.get(\"input_tokens\",0)}, cache_create: {first.get(\"cache_creation_input_tokens\",0)}, cache_read: {first.get(\"cache_read_input_tokens\",0)}, total: {first.get(\"input_tokens\",0)+first.get(\"cache_creation_input_tokens\",0)+first.get(\"cache_read_input_tokens\",0)}')
    print(f'Last msg  — input: {last.get(\"input_tokens\",0)}, cache_create: {last.get(\"cache_creation_input_tokens\",0)}, cache_read: {last.get(\"cache_read_input_tokens\",0)}, total: {last.get(\"input_tokens\",0)+last.get(\"cache_creation_input_tokens\",0)+last.get(\"cache_read_input_tokens\",0)}')
    print(f'Growth: {(last.get(\"input_tokens\",0)+last.get(\"cache_creation_input_tokens\",0)+last.get(\"cache_read_input_tokens\",0)) - (first.get(\"input_tokens\",0)+first.get(\"cache_creation_input_tokens\",0)+first.get(\"cache_read_input_tokens\",0))} tokens')
"

If "Growth" is significantly larger than expected from your conversation text alone, file change notifications may be accumulating. Please share your results and CC version.

Root cause analysis (traced from the v2.1.88 source leak):

The file change notification pipeline has no cleanup mechanism:

1. L2Y runs every turn, scanning all files CC has ever read in the session. Any mtime change generates a diff.
2. f47 wraps the diff in a <system-reminder> user message with isMeta: true — these are permanent and never pruned.
3. The main loop concatenates all accumulated messages (including old notifications) into every subsequent API call.
4. The only thing that clears them is autocompact, which doesn't fire until context already exceeds ~100K tokens.

Result: Each unique file modification creates a permanent message in the conversation. Linters, formatters, and auto-save each trigger new notifications. readFileState grows monotonically (every file ever read), expanding the scan surface.

Suggested fixes (ordered by impact):

1. Make notifications ephemeral — inject for the current API call only, don't persist in conversation history
2. Deduplicate per filename — keep only the latest notification per file
3. Cap diff snippet size
4. Add TTL-based pruning for isMeta file change messages

Still reproduces on 2.1.92 — the code path is unchanged.

Closing as duplicate of #4464 — same root cause. Posted the source-level analysis there.

Root cause analysis and discussion moved to #4464 — the canonical issue for this bug.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.