Auto-memory system not used proactively during multi-session troubleshooting; user forced to re-explain 30+ hour saga

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?

Claude Code has an auto-memory subsystem at ~/.claude/projects/<project>/memory/ that persists across sessions and is documented to be used for "user",
"feedback", "project", and "reference" memories. The system prompt explicitly instructs Claude to "save memories proactively" during multi-step fixes.

In practice during a multi-session real-world troubleshooting task (renaming a Time Machine disk on macOS Tahoe and configuring a shared TM destination across
two Macs), Claude:

1. Did NOT proactively save state across or within sessions despite the work spanning ~30+ hours and multiple Claude Code restarts
2. Started fresh sessions with zero context of prior diagnostic work and asked the user to re-explain everything
3. Even within a single session, repeatedly cycled through generic "common fix" suggestions from training instead of reading the actual filesystem state

available via Bash (e.g., the ACL on the volume, the dscl SharePoint record) — both of which would have given the answer in one read

1. Ignored a saved feedback memory ("Search the web before reasoning from first principles on real-world tech problems") on multiple turns until the user

explicitly called it out

The user's frustration was severe and repeated. Memory clearly exists to prevent exactly this failure mode, but Claude treated it as something to populate
reactively (after a failure / when user complains) rather than continuously during work.

What Should Happen?

For multi-step real-world troubleshooting tasks (anything involving real systems: disks, networking, hardware, OS config, multi-session fixes), Claude should:

1. Save a project memory at the START of any non-trivial troubleshooting task capturing: stated goal, system state (relevant filesystem/config values verified

via tool calls), what's been tried, what failed

1. Update that memory at every meaningful checkpoint (each diagnosis, each failed attempt, each user correction)
2. On any new session, BEFORE asking the user anything, read the memory directory and summarize prior context so the user can correct/extend rather than

re-explain

1. Treat saved feedback memories ("search first," etc.) as binding rules, not soft hints — if Claude is about to suggest an approach that violates a saved

rule, the rule should win

Currently the prompt describes this behavior but Claude does not actually do it consistently.

Error Messages/Logs

Not a crash

Steps to Reproduce

1. Configure auto-memory (already set up by default in current versions).
2. Start a Claude Code session with a multi-step real-world troubleshooting task that will require multiple sessions or hours to resolve. Real example: "I need

to rename an external Time Machine SSD and configure it as a shared TM destination for a second Mac."

1. Work the problem with Claude across multiple sessions or interruptions.
2. Observe: at session boundaries, Claude does not check memory before asking. Within a session, Claude cycles through generic suggestions despite filesystem

evidence being one Bash call away.

1. Trigger a course correction by manually telling Claude "you forgot." Observe Claude only NOW saving the context that should have been saved hours ago.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.132

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Secondary observation worth flagging: the ! prefix Claude Code uses for inline command execution conflicts with zsh history expansion when users paste
Claude's suggested commands into their own shell. Claude suggested !sudo sharing -r "Time Machine" and the user's zsh expanded !sudo to a previous
unrelated sudo killall... command, producing a mangled command. Recommend either avoiding the ! prefix in suggested copy-paste commands or warning users
about zsh history-expansion clashes.

The user has given clear permission to share details of this session if useful for diagnosis.