The Claude Code agent falsely claims that its memory is project-agnostic.

Summary

The Claude Code system prompt describes the auto-memory system but doesn't explicitly state that memory is (a) local to the machine and (b) scoped per-project (per working directory). The model confabulates plausible-sounding details when the user asks about these properties, and only corrects itself after the user (or an explicit ls of the directory) surfaces the truth.

Concrete example

In a recent session, Claude (Opus 4.7 in Claude Code) told the user:

"memory travels with your Anthropic account rather than the local machine"

This is wrong. The memory directory is at ~/.claude/projects/<sanitized-cwd>/memory/ — obviously local and project-scoped. The path was in the system prompt from the start; the model just didn't inspect it.

Downstream, the model then recommended mirroring style rules to memory "as backup for cross-machine sync." That recommendation only makes sense under the wrong belief about memory scoping.

What would help

1. Make the system prompt explicit about memory scoping. Add something like: "Memory is stored locally at <path>. It is scoped per-project (per working directory) and does not sync across machines or Anthropic accounts."

1. Add a discouragement: "Do not describe properties of the memory system (portability, sync, scope) beyond what is stated here. If the user asks about properties not documented above, say you don't know."

1. Fix a related inaccuracy already in the current system prompt. It states: "This directory already exists — write to it directly with the Write tool (do not run mkdir or check for its existence)." Empirically, on a fresh install, the directory does NOT exist until the first Write. Small but real error.

Environment

• Claude Code CLI (current)
• Model: \claude-opus-4-7\
• Platform: macOS (Darwin 25.5.0)

Broader pattern

This is a specific instance of a general failure mode: the model produces fluent, plausible-sounding claims about system internals without checking primary sources available in its own context. Explicit system-prompt constraints ("if this isn't documented here, say you don't know") are probably the most tractable fix.