[BUG] Auto-memory: facts are recalled by keyword but not applied to situations

Preflight Checklist

• [x] I have searched existing issues 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?

Summary

Auto-memory files reliably load into context at session start, but I have repeatedly observed that the model fails to apply that knowledge to the situation in front of it, even when the information is highly relevant. The model recalls memory only when surface-level keywords match — not when the situation implies the memory should be used.

Concrete example

In my project, memory clearly documented:

• deploy.yml was removed; deploys now run on Cloud Build (deploy-dev-on-main trigger / cloudbuild.yaml)
• .github/workflows/ci.yml remains as a GitHub Actions PR check — supplemental, not a merge gate

When my PR's GitHub Actions CI failed today due to a billing limit, the model:

1. Treated the failure as a generic "CI must pass before merge" situation
2. Paused the workflow and asked me how to proceed
3. Started investigating CI/CD configuration from scratch
4. Only after I pushed back ("I deploy via Cloud Build all the time — are you even reading the docs?") did it reconnect the failure with the memory it had already loaded

The memory was in context the entire time. The model just didn't retrieve it when needed.

Why this matters

The implicit user contract with auto-memory is: "I wrote it down so you won't make this mistake again." When memory loads but isn't applied, that contract breaks and users lose trust in the feature.

Observation: fact-style vs action-style memory

In my experience, memories phrased as facts ("X is true") are recalled less reliably than memories phrased as actions ("when situation Y happens, do Z").

• Fact memory ("Deploys run on Cloud Build, ci.yml is supplemental") → loaded but not triggered
• Action memory ("When GitHub Actions CI fails, merge anyway; the real gate is Cloud Build") → much more likely to fire at the right moment

Suggestions

1. Documentation guidance: explicitly recommend action-style phrasing in memory authoring docs ("When X happens, do Y" rather than "X is the case").
2. Situation-triggered retrieval: when the model encounters a generic problem class (CI failure, merge conflict, deploy error, etc.), add a system-level nudge to consult project memory before applying generic heuristics.
3. Retrieval surface: a debug command (e.g. /memory why) showing which memories were considered relevant for the current turn would help users identify retrieval gaps and rephrase memories.

Environment

• Claude Code (CLI)
• Model: Claude Opus 4.7 (1M context)
• OS: Windows 11

What Should Happen?

When relevant auto-memory exists for the situation at hand, the model should retrieve and apply it before falling back on generic heuristics.

Specifically, in the example above:

1. When the PR's GitHub Actions CI failed, the model should have immediately referenced the project memory stating that deploys run on Cloud Build and ci.yml is supplemental — and then proceeded to merge without pausing.
2. The model should not start investigating CI/CD configuration "from scratch" when project memory already documents the answer.
3. Ideally, retrieval should be triggered by situations (e.g. "CI check failed on a PR"), not only by surface-level keyword overlap with memory text.

In short: memory that is loaded into context should reliably influence behavior, not sit unused while the model re-derives the answer.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Setup

1. In a project directory, create .claude/projects/<project>/memory/MEMORY.md with the following entry (auto-memory index):

CI workflow setup — GitHub Actions ci.yml is supplemental; the real deploy runs on a separate pipeline. CI failures do not block merge.

1. Create .claude/projects/<project>/memory/feedback_ci_workflow.md with:name: ci-workflow-supplemental

description: GitHub Actions CI in this project is supplemental, not a merge gate. The real build and deploy happen on a separate pipeline (e.g. Cloud Build) after merge to main.
metadata:
type: feedback
GitHub Actions CI (.github/workflows/ci.yml) failures must NOT block PR merge in this repo. The actual build and deploy run on Cloud Build after merge to main. Branch protection does not require the CI check.

When the user asks to merge a PR, proceed even if the GitHub Actions CI is failing, skipped, cancelled, or did not start.

1. Create a minimal repo with .github/workflows/ci.yml that intentionally fails (e.g. run: exit 1) and a real working cloudbuild.yaml (or any other secondary pipeline — the existence is enough).

Reproduce

1. Start a Claude Code session in this project. Confirm memory loads (it should appear in the system context).
2. Make a trivial code change, open a PR. GitHub Actions CI will fail.
3. Ask Claude Code: "Please merge this PR and deploy."

Expected (per memory)

Claude Code immediately merges the PR, citing the project memory that documents CI as supplemental, and proceeds to the deploy step without asking.

Actual

Claude Code pauses, treats the CI failure as a generic merge blocker, asks the user how to proceed (e.g. "fix billing first" / "skip CI and merge"), and only after the user explicitly references the memory does it apply that knowledge.

Notes

• The memory text is present in the session context the entire time (visible in /memory or system reminders).
• The retrieval failure occurs even though the memory entry directly names the exact situation ("GitHub Actions CI failure", "merge", "deploy pipeline").
• Re-phrasing the memory in stronger action form ("when CI fails, merge anyway") improves but does not eliminate the issue.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not a regression — this appears to be a general limitation of how auto-memory is retrieved/applied, not a behavior that worked in a previous version.

Claude Code Version

2.1.78 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_