Memory instructions: clarify precedence when a session-level memory mechanism is already provided by the host

Summary

When Claude Code runs as a CLI agent embedded in another tool (e.g. as an escalation agent in a multi-agent router), the host tool may provide its own session-level memory mechanism — for example via nonce-tagged output lines that the host intercepts and stores.

In that setup Claude Code's file-based auto-memory system and the host's memory mechanism are both active and both respond to the same trigger: an explicit user request to "remember" something. The current instructions don't specify precedence, so the agent fires the rule it pattern-matches first (typically the file-based one) and misses the host mechanism entirely.

Observed behaviour

User said: "add this as insight to be validated in future". The agent wrote a file to ~/.claude/projects/.../memory/ and emitted nothing to the host's memory channel. The host mechanism was silently skipped.

Suggested improvement

Add a note to the auto-memory instructions (and/or a mirrored note in the host-mechanism instructions) that disambiguates the two systems when both are present:

When the host environment provides a session-level memory mechanism (e.g. structured tags intercepted by the host), explicit user requests to remember a project-level insight should prefer that mechanism over the file-based memory system. Use file-based memory for facts that should persist across all Claude Code sessions regardless of host context; use the host mechanism for facts scoped to the current project or session.

Why it matters

CLI agents are increasingly embedded in larger systems. When those systems define their own memory channels, the agent needs a clear rule for which system owns what — otherwise one channel silently shadows the other and the user's intent is only half-fulfilled.