claude-code - 💡(How to fix) Fix Feature request: hook surface that fires before memory injection (so users can dedup duplicate rule content) [1 participants]

Problem

When a user organises their codebase with git worktrees + symlinks (a common pattern for parallel feature branches), Claude Code can inject the same rule file's content twice into a single session's memory block. The duplicate paths resolve to the same on-disk content via the symlink, but the loader treats them as distinct injection sources.

Symptoms observed:

• A single rule file's body appears twice in the memory block
• The duplication scales with the number of overlapping memory paths — e.g. ~165 KB of duplicate rule content per session in a worktree-heavy workflow
• The duplicate content burns context budget on every session start and every memory refresh
• More importantly: it creates a silent override risk. If the loader ever returns two different snapshots of the same rule (one from a stale cache, one fresh), the second injection silently overrides the first with no warning

The root cause is that the memory loader has no extension point. Hook taxonomy currently exposes SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, PostToolUseFailure, and PreCompact — but memory injection happens inside the binary BEFORE any hook fires. SessionStart runs post-injection, so it cannot un-inject content already in the system prompt.

Proposed surface

Add a PreMemoryLoad (or similarly-named) hook surface that fires AFTER the loader has computed its planned injection list but BEFORE it commits the list to the system prompt. The hook receives the planned list as JSON on stdin, can return a transformed list, and the loader uses the transformed list as the final injection.

This is the same shape as the existing PreToolUse hook, just at a different point in the lifecycle.

Why content-hash dedup is the right strategy

The natural-seeming alternative — dedup by realpath (collapse symlinks to canonical path, then dedup) — is necessary but not sufficient. It correctly dedups the symlink-driven duplicate case, but it ALSO collapses intentionally-different worktree-local rule overrides (e.g. an experimental rule edit on a feature branch). That's a false dedup that hides the override.

Content-hash dedup (SHA-256 the body, dedup on hash) handles both cases correctly:

• Same content → same hash → only one injection (intended dedup)
• Different content → different hashes → both injected, with the conflict visible in the memory block (intended override)

A user-supplied PreMemoryLoad hook can implement either strategy, but the platform's own behaviour should not silently collapse overrides.

Workaround in use today

Without a pre-injection hook, the only available mitigation is documenting the issue as an advisory rule and asking users to /clear periodically when the duplicate-injected memory block becomes a problem. This works but is manual.

Impact

• Token-budget impact: linear in session count × overlap × rule-surface size. For users with multi-worktree workflows and large rule surfaces this is a non-trivial recurring cost.
• Correctness impact: silent override is the deeper concern. A pre-injection hook that dedups by content-hash makes the silent-override path impossible by construction.

Acceptance criteria

A user-supplied script registered as PreMemoryLoad can:

1. Receive the planned memory injection list (paths + content) as JSON on stdin
2. Return a transformed list (subset, reordered, or dedup'd) on stdout
3. Have the loader use the transformed list as the final injection

The hook fires for every memory refresh, not only session start.