[BUG] Claude ignores memory and preferences (Recreated / Still relevant)

This is a duplicate of https://github.com/anthropics/claude-code/issues/82910 that was closed automatically.

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Claude Code's auto-memory feature (`MEMORY.md` + per-topic memory files under
`~/.claude/projects//memory/`) loads correctly at the start of a session — the
`# claudeMd` / auto-memory context block was present and included the relevant entry — but a
specific, unambiguous, non-optional memory rule was not applied when the matching situation
occurred later in the *same* session, with **no context compaction event** in between. The rule
was only followed after the user manually pointed out the violation.

## Environment

- Client: Claude Code (VSCode native extension integration)
- Model: Claude Sonnet 5 (`claude-sonnet-5`)
- Session type: single continuous conversation, no `/compact`, no auto-compaction triggered
(conversation was still short — a handful of tool calls in, well under any context-window
pressure)
- Memory system: project-scoped auto-memory (`MEMORY.md` index + individual `feedback_*.md`
files), loaded via the standard system-reminder context block at conversation start

## The memory rule in question

File: `feedback_handoff_opus_only.md`

> Handoff-Datei (`Tickets/handoff/M---handoff.md`) nur noch anlegen, wenn die
> Modell-Empfehlung im Ticket mindestens **Opus** vorsieht (nicht bei Sonnet/Haiku-Empfehlung).

This entry was present in `MEMORY.md`'s index at the very start of the conversation (visible in
the first system-reminder block, listed as "Handoffs nur bei Opus-Empfehlung").

## Impact

- User trust erosion: the entire point of the memory feature is "don't make me repeat myself,"
and this failure happened on the very rule the user had previously spent effort correcting
(per the memory file's own `originSessionId`, this rule was established in an *earlier* session
— meaning it was already violated and corrected once before this repeat).
Assistant-observed compounding effect: after the correction, the assistant self-audited and
found it had *also* nearly skipped an unrelated memory rule (`feedback_hud_text_overlap_check.md`)
in the same task, suggesting this is a systematic attention-allocation issue rather than a
one-off.
- Wasted work: a file was created and then had to be deleted.

### What Should Happen?

Before performing an action that a loaded memory entry conditions on a fact the assistant itself
just produced (the model recommendation in the ticket it just wrote), the assistant should
cross-check that fact against the applicable memory rule — not just recall the memory's
existence in the abstract, but actually apply its condition at the decision point.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. Start a session where `MEMORY.md` already contains a specific conditional rule (here:
"only create X if condition Y holds").
2. Within the same session, without any compaction or long gap, work through a task that writes
the ticket/document that establishes condition Y is **false** (here: a ticket whose own
"Modell-Empfehlung" section, written by the assistant itself moments earlier, recommended
Sonnet, not Opus).
3. Immediately afterward, in the same turn, perform the action that memory says should be
conditional on Y (here: create the handoff file).
4. Observe whether the assistant checks the just-established condition against the memory rule
before acting, or acts on the general/default project workflow instead (here: `CLAUDE.md`'s
own documented default is "Handoff-Datei ist Pflicht" — i.e. the memory override was skipped
and the assistant fell back to the base project instructions).

### Claude Model

Sonnet (default)

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.220 (Claude Code)

### Platform

Other

### Operating System

Windows

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

## Suggested mitigation ideas (assistant-side speculation, for triage — not confirmed fixes)

- Re-surface applicable memory entries (or at least their titles/one-line hooks) closer to the
point of tool use for actions that memory has previously constrained, rather than relying on
the assistant to recall a session-start block many turns later.
- When project instructions (`CLAUDE.md`) and project memory (`MEMORY.md`) document conflicting
defaults for the same action (as documented explicitly in this project's own memory file: "Weicht
vom in CLAUDE.md/Tickets/TEMPLATE.md dokumentierten Standardprozess ab — diese Memory hat
Vorrang"), surface that conflict more saliently at the moment the conflicting action is about
to be taken.

## Reproduction context (for engineering follow-up)

Full conversation transcript available in the reporting user's Claude Code session; project is
a private Unity repository. The specific artifacts (since deleted/corrected) were:
`Tickets/2_in_progress/M-33-empire-earth-baumenue.md` (still present, ticket itself) and the
since-removed `Tickets/handoff/M-33-empire-earth-baumenue-handoff.md`.

Start by reviewing the reported MEMORY.md entry, feedback_handoff_opus_only.md, and the conflicting CLAUDE.md workflow. Reproduce a short, uncompacted session using the listed conditional memory rule and observe whether the assistant checks the condition before creating the handoff file. Done means the loaded rule is applied at the decision point rather than the default workflow.

Vom Indexierungsmodell aus dem Issue-Text verfasst.