Adjudication step for auto-memory — batched promote/keep/discard review

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 17, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Auto-memory maintains a clean provenance separation (machine-written notes never touch human-authored CLAUDE.md files), but has no adjudication mechanism. Because MEMORY.md loads into context at the start of every session, its contents accrue de facto instruction authority over time — unreviewed, per-machine, and invisible unless the user runs /memory. This quietly produces the outcome the two-store separation was designed to prevent: unratified agent inferences steering behavior with instruction-like weight.

Why this matters:

  1. Authority leak. The stated rationale for keeping auto-memory out of CLAUDE.md is that unreviewed agent inferences shouldn't carry instruction authority. But loading them into every session grants that authority anyway — just gradually and invisibly, which is worse for debuggability than an explicit write would be.
  2. Per-machine divergence. Two developers on the same repo accumulate different memory stores, so "identical committed config" no longer implies "similar agent behavior." Without a review step, there's no natural moment where divergent learnings get reconciled into the shared CLAUDE.md.
  3. Silent staleness. A misinference recorded once (e.g., a wrong belief about the API layer) persists and compounds across sessions until a user happens to audit /memory.

Proposed Solution

Add a batched ratification pass — periodically surface accumulated learnings to the user with promote-to-CLAUDE.md / keep-in-memory / discard options. This complements #34776 (memory governance): that issue proposes auditing memory in place; this one proposes the write path that routes ratified content out of memory.

Proposed mechanism:

Extend the existing memory consolidation pass (which already rewrites, prunes, and reorganizes memory files during idle time) to end with a human ratification step:

  1. During consolidation, classify accumulated items into candidate buckets:
  • Promote — stable, generally-true, team-relevant → propose as a diff to project CLAUDE.md (or user ~/.claude/CLAUDE.md for personal preferences)
  • Keep — personal/provisional/machine-specific → remains in memory
  • Discard — stale, superseded, or contradicted by CLAUDE.md
  1. Surface the batch at a natural boundary (session start after N sessions, or on demand via something like /memory review), with one-keystroke accept/reject per bucket or per item.
  2. On promote, write the change to CLAUDE.md as a normal edit the user can commit through code review — preserving the human-ratification gate for anything entering the shared instruction layer.
  3. Flag contradictions explicitly: any memory item that conflicts with a CLAUDE.md instruction should be queued for adjudication rather than left to inference-time judgment.

This amortizes review cost across many items (unlike per-item prompts), closes the authority leak (unlike the status quo), and reuses machinery that already exists — the consolidation pass is most of the plumbing; what's missing is the ratification step at the end of it.

Alternative mechanisms considered

  • Per-item approval prompts: too interruptive; measures the wrong thing (see above).
  • Agent writes directly to CLAUDE.md: breaks the provenance separation; unreviewed inferences would gain instruction authority immediately, and autonomous writes to a committed file mean either perpetual dirty working trees or unreviewed content propagating to the team.
  • Status quo: provenance-coherent but adjudication-weak; authority leaks slowly instead of directly.

Alternative Solutions

I can periodically ask Claude to propose updates to my user's and projects CLAUDE.md. But that puts the onus on me to remember to do it regularly, and requires me to know that this is a thing.

I could disable the use of memory altogether. So that prevents the problem of shadow instructions, but loses the benefit of a Claude-driven cycle of self-improvement

I could set up softlinks from the machine's memory files to a project-specific file, but that will just cause chaos.

I could go use codex instead, but it's just as likely to make paternalistic choices, albeit maybe different ones.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗