[FEATURE] Automatic memory recall at session start

Open 💬 2 comments Opened Jun 24, 2026 by muncrief

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

<!-- Created: 2026-06-23 19:38 | Last change: 2026-06-23 19:38 — Anthropic feedback submission draft -->

Anthropic Feedback — Claude Memory System: Session Launch Pattern

Submitted by: rmuncrief@humanavance.com
Date: 2026-06-23
Category: Claude Code — Memory System / Session Startup UX

---

Summary

Claude's memory system (CLAUDE.md @imports + SessionStart hooks) can be fully configured
to provide rich project context at session start. However, even with everything correctly
wired, Claude does not reliably act on that memory without an explicit opening prompt.
A user discovered a working solution: pass the memory-reading instruction as Claude's
opening argument in the terminal launcher. This pattern should either be documented
prominently or made unnecessary by improving the default session startup behavior.

---

The Problem

With a properly configured memory system:

  • CLAUDE.md @imports ~40 memory files
  • A SessionStart hook outputs a ~1.3KB briefing from session_briefing.md

...Claude still does not automatically read and act on those files at session start
without being explicitly told to do so. The briefing appears in system-reminder, but
without an explicit opening prompt, Claude may respond to the user's first message
before fully processing the loaded memory. This defeats the purpose of the memory
system for users who rely on it for project continuity.

Multiple attempts were required to get Claude to reliably read memory files first,
before addressing any user input. The solution required significant trial and error
by an experienced engineer. Non-engineer users would almost certainly fail at this.

---

The Solution — Terminal Launcher Pattern

Pass the memory-reading instruction as Claude's opening argument when launching.
Claude then processes memory as its first action before receiving any user input.

General pattern:

<terminal-emulator> --default-working-directory=<project-path> \
  --command 'claude "<memory-reading prompt>"'

Concrete working example (CachyOS Linux, XFCE desktop):

xfce4-terminal \
  --default-working-directory=/home/<user>/Projects/Linux/AI/Claude \
  --command '/home/<user>/.local/bin/claude "Read every file in \
  /home/<user>/.claude/projects/<project-memory-path>/memory/ starting with \
  MEMORY.md, then read all files listed there for the current project. \
  Present the startup briefing from session_briefing.md verbatim. \
  Do nothing else until that is done."'

Terminal emulator equivalents for other desktop environments:

  • GNOME: gnome-terminal --working-directory=<path> -- claude "<prompt>"
  • KDE: konsole --workdir <path> -e claude "<prompt>"
  • Windows Terminal: wt -d <path> claude.exe "<prompt>"

---

What Anthropic Could Do

Option 1 (best): When a SessionStart hook is configured and CLAUDE.md contains
@imports, have Claude automatically read and acknowledge those files before processing
the first user message. This is the expected behavior given the system design; it just
doesn't happen reliably today.

Option 2: Document this launcher pattern prominently in Claude Code docs under
"Memory System / Session Startup." Many users configure memory and then wonder why
Claude doesn't seem to use it. This is the reason, and the fix is not obvious.

Option 3: Add a --prompt or --init-prompt flag to the claude CLI that
accepts an opening instruction. Cleaner than embedding a long string in a shell command,
and makes the intent explicit in the launcher definition.

---

Why This Matters

The memory system is one of Claude Code's most powerful features for users doing
ongoing, multi-session project work. If it doesn't reliably activate at session start,
users either don't benefit from it or spend significant time re-establishing context
manually on every session. The launcher pattern works, but discovering it required
multiple failed attempts and engineering-level debugging. Most Claude Code users are
not in a position to work through that.

The user who discovered this explicitly asked: "Can you learn this so others don't
have to go through what I went through?" That's the spirit of this feedback.

---

Submission path

https://github.com/anthropics/claude-code/issues — file as a new issue.
Or use the in-app feedback button if available.

Proposed Solution

Implement a generic way for general and project specific memories to be recalled at startup.

Alternative Solutions

I had to create a special launcher with a specific command, and Claude had to create some files on your end, to achieve this simple task.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I'm working on a project and begin a Claude session expecting that it will recall all of its generic memories and current project memories. But it does not. Even if I specifically ask that they be remembered.

And so I waste uncounted hours of development time until I happen to stumble upon some phrase say that causes Claude to recall a critical local memory. And then usually solve the problem much quicker, because we don't have to go through everything we went through before.

Additional Context

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗