Feature request: per-project memory file size limit (% of context window)

Problem

Memory files (CLAUDE.md, project memory under \~/.claude/projects/\) grow unboundedly. Once they exceed a significant fraction of the model's context window, effective context shrinks rather than grows — the opposite of what memory is for. There is no mechanism to limit size, warn the agent, or block oversized writes.

Proposed solution

A configurable memory file size limit as a % of the model's context window, with three enforcement levels:

| Usage vs. limit | Behaviour |
|---|---|
| < 85% | After each write: brief passive note — [memory-guard] Memory at 12.4% (this edit +0.3pp) |
| ≥ 85% | Warning injected: "Approaching limit — reduce redundant entries before the next edit or you may be blocked." |
| > 100% | Write blocked before executing: "Memory edit blocked: this would bring memory to X% of the Yk context, exceeding the Z% limit." |

Configurable per-project (e.g. 3 / 5 / 10 / 20 / 30 / unlimited). Default: unlimited — no behaviour change for existing users.

Why percentage, not tokens: Different models have different windows (200k vs 1M). A percentage scales automatically with the active model.

Why this matters

Without a budget, agents fill memory with verbose low-density entries until the file is too large to load coherently. The limit creates structural pressure to keep entries terse and purposeful. The 85% soft warning gives the agent a chance to prune before the hard wall.

Implementation sketch (hooks-based, works today)

Already running in production using Claude Code hooks:

• PreToolUse on Write/Edit: if path is inside the memory dir, compute projected token count; output {"decision": "block", "reason": "..."} if over limit.
• PostToolUse on Write/Edit (continueOnBlock: true): compute post-edit count; inject informational/warning feedback. The continueOnBlock option makes this clean — the agent sees the reason without the tool being blocked.

Native support would be more robust (no hooks required, survives model switching, works in all environments).

Community evidence

This is a recurring pain point across the user base:

• #29971 — Context Bloat: Bug Report + Community Issue Tracker — community-tracked umbrella issue; CLAUDE.md and memory growing unbounded cited as a top contributor
• #46526 — Token efficiency: system prompt overhead consumes too much context — confirms always-loaded memory files are a primary driver of context waste
• #49593 — 2.1.111 introduced ~14% context window bloat at session startup — shows how even small additions to always-loaded memory compound quickly
• #27298 — Feature request: layered memory system for persistent cross-session context — community reaching for workarounds because the current system has no size governance
• #34556 — Feature request: persistent memory across context compactions — users building their own memory compaction tools, pointing to the same gap