[FEATURE] Dreaming: surface CLAUDE.md promotion candidates to humans

Resolved 💬 2 comments Opened May 17, 2026 by tiktax Closed Jun 16, 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

Claude Code has two memory layers with fundamentally different load guarantees:

| Layer | File | Load behavior |
|---|---|---|
| Instruction layer | ~/.claude/CLAUDE.md | Every session, full content |
| Auto memory | ~/.claude/projects/.../memory/*.md | On-demand only (MEMORY.md index: first 200 lines) |

Dreaming writes exclusively to the auto memory layer. Rules it extracts are not guaranteed to be in context when they are needed. The only way to ensure a rule applies every session is to manually copy it into CLAUDE.md — but nothing prompts the human to do this.

Real Incident Chain

Incident A (day 0): An agent violated a security rule — running a shell command that caused sensitive credential output to appear in the session transcript. The rule prohibiting this command pattern was documented and saved to auto memory after the incident.

Incident B (day 5): The exact same violation recurred. The rule from Incident A was present in auto memory but had never been promoted to CLAUDE.md, so it was never loaded in the intervening sessions.

The same failure mode appeared across multiple unrelated incidents:

  • Security rule (command prohibition) → written to auto memory → not promoted → re-triggered 5 days later
  • Git workflow rule → sat in auto memory for weeks, only discovered during a manual audit
  • Agent coordination rule → same pattern

In each case, discovery worked correctly. The gap was in surfacing the promotion decision to the human.

Proposed Solution

Add a classification step to Dreaming's analysis:

  1. Criticality scoring — when a pattern is extracted, evaluate whether missing it in a future session could cause a repeat failure (security violation, broken workflow, data loss)
  2. Promotion flag — if the pattern scores above a threshold, annotate it in MEMORY.md with a [promote-to-CLAUDE.md] tag or equivalent
  3. User notification — surface the candidate at session start or end: "Dreaming found 1 rule that may belong in CLAUDE.md. Run /memory to review."

The human still makes the final promotion decision, preserving the design intent that CLAUDE.md is human-authored. Dreaming only closes the notification gap.

Alternative Solutions

Currently the only option is periodic manual audits of feedback_*.md files. This is error-prone — the audit itself only happened because of an explicit investigation session, not as a normal workflow.

Priority

Medium — prevents repeat incidents that pass through the discovery step correctly but fail at the promotion step.

Feature Category

Memory / Dreaming

Use Case Example

  1. Agent violates a rule; Dreaming extracts the corrected behavior and writes it to feedback_security.md
  2. Today: nothing notifies the human → rule sits in on-demand memory → same violation recurs next week
  3. With this feature: Dreaming flags the rule as a promotion candidate → human sees notification at next session start → promotes to CLAUDE.md → violation cannot recur

Related

  • #38493 — Dreaming output quality (accuracy, identity, transparency). This request is different: it targets the architectural split between always-loaded and on-demand memory, not output correctness.
  • Auto memory docs: https://code.claude.com/docs/en/memory

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗