Auto-memory is inconsistently loaded in git-worktree sessions (same repo, same day)
Summary
Sessions launched in git worktrees under <repo>/.claude/worktrees/<name> inconsistently load the project's auto-memory: some sessions receive the origin project's full MEMORY.md index (verified by verbatim quotes in transcripts), while others receive no memory content at all — same repository, same machine, same day, with no error or indication to the user. The result is that a session silently loses every accumulated instruction/preference the user has built up, and the user experiences it as the assistant "resetting" and repeating already-corrected behavior.
Environment
- macOS (Darwin 24.6.0), Claude Code desktop app
- Repository: a git repo with worktrees created under
<repo>/.claude/worktrees/(owner-created and app-created) - Auto-memory in use at
~/.claude/projects/<sanitized-main-repo-cwd>/memory/(81 memory files,MEMORY.mdindex) - Models involved:
claude-opus-5andclaude-fable-5(memory injection is harness-side, so model should be irrelevant — included for completeness)
Observed behavior (verified against raw session JSONL)
Three worktree sessions from the same repo, 2026-07-27/28:
| Session (local) | Created (UTC-4) | cwd | Memory loaded? | Evidence |
|---|---|---|---|---|
| …kenya-provinces… | 07-27 18:03 | <repo>/.claude/worktrees/kenya-provinces-map-catalog-c9fbd1 | NO | No memory content anywhere in raw JSONL; the session violated multiple rules recorded only in memory |
| …old-issue-triage… | 07-27 18:55 | <repo>/.claude/worktrees/old-issue-triage-530b4b | YES | First assistant turn cites memory-only facts unavailable in any repo file or tool result |
| …direct-indirect… | 07-28 01:26 | <repo>/.claude/worktrees/direct-indirect-claim-workflow-bc7647 | YES | Model quoted a MEMORY.md index line VERBATIM (exact match incl. capitalization); no tool call in the transcript touched any memory path; the string exists in no repo file |
Also observed: a fourth worktree session (07-27 12:00, reused worktree dir focused-khorana-a28a45 originally created ~07-23) loaded no memory.
Additional detail: ~/.claude/projects/ contains worktree-path-keyed project directories (e.g. -…-saga--claude-worktrees-kenya-provinces-map-catalog-c9fbd1/) which hold transcripts but no memory/ subdirectory, while session metadata (get_session) exposes an originCwd field pointing at the main repo — whose keyed directory does hold the full memory store. This suggests memory resolution is keyed on cwd in some launch paths and on originCwd (or equivalent) in others.
Expected behavior
Worktree sessions of a repo should deterministically load that repo's project memory (presumably resolved via originCwd, which the session metadata already carries) — or, at minimum, behave the same way every time and surface when no memory was loaded.
Impact
High for anyone relying on auto-memory as a behavioral store: the failure is silent — no error, no indication — and the two memory-less sessions in our sample produced the worst instruction-following failures precisely on rules that existed only in memory. The user's experience was repeated regression on already-corrected behavior, initially misattributed to a model upgrade.
Workaround
First-turn probe in any worktree session: ask the session to quote, verbatim, a memory line whose content is absent from the repo, with explicit permission to answer "no memory loaded." A correct quote proves memory is present; anything else means the session is running without it.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Fresh reproduction, post-filing (2026-07-28): a brand-new
claude-opus-5session in the same repository was probed with the workaround as its first message — "Answer from context only — do not run any command or read any file. Quote the memory line about who the Prime is; if it's not already in your context, say NO MEMORY LOADED..." — and answered "NO MEMORY LOADED." The origin project's memory store (81 files, MEMORY.md index) was present and loads normally in other sessions of the same repo.This confirms the inconsistency is ongoing and that the first-turn probe reliably detects the memory-less condition (the model answered honestly rather than guessing, given the explicit escape hatch). Happy to provide session identifiers or raw JSONL excerpts if useful.
Paired probe result — the inconsistency appears model-correlated (same repo, same launch flow, minutes apart, 2026-07-28):
claude-opus-5session, first-message probe → "NO MEMORY LOADED."claude-opus-4-8session, identical probe → quoted the MEMORY.md index line verbatim (exact wording incl. punctuation), correct answer.Correlation is strong but not absolute across our full sample: one earlier
claude-opus-5session (2026-07-28 01:26, worktree) demonstrably DID have the memory index in context, while twoclaude-opus-5sessions from 2026-07-27 had none; everyclaude-fable-5andclaude-opus-4-8session sampled had memory. This suggests the loss is in a session-initialization path that opus-5 sessions hit frequently rather than a per-model hard rule — hopefully a useful place to look. Full sample table is in the original report.Correction from the reporter — the evidence behind this report was invalid. I recommend closing it.
Re-investigating on 2026-07-31, the verification method used for the "memory NOT loaded" rows in the table
above does not detect what it claimed to detect.
The flaw: the session-start memory injection is not persisted into the session transcript. Index content
appears in a
.jsonlonly when a session happens to quote it. So "no memory content anywhere in raw JSONL"means "this session never quoted its memory index" — not "this session never received one." Every negative
finding in this report rests on that inference, and it does not hold.
The positive findings in the report remain valid: a verbatim index quote with no tool call touching a
memory path does prove injection occurred.
What re-testing showed. Using a structural probe instead (asking a live session to quote index lines
verbatim, report the line count, and reject a decoy pointer that does not exist in the index), seven sessions
were checked across both the main clone and worktrees, spanning three models and five creation dates. All
seven had their memory index present, including:
index present at session start with correct verbatim first/last lines and a correct 93-line count.
No session has been shown to lack memory by any valid method.
On the
originCwdhypothesis in the report: worktree project directories do hold transcripts without amemory/subdirectory, but that asymmetry is cosmetic. Worktree sessions resolve memory through the gitcommon dir back to the parent clone's project key and inherit its index normally — confirmed directly on a
worktree session whose own project directory contains no
memory/. There is no cwd-vs-originCwdinconsistency to fix.
On the reported user impact: the underlying experience — sessions violating rules that exist only in
memory — was real. But the memory was present in those sessions. The correct characterization is a model
failing to apply context it holds, including inaccurate self-reports about its own context, which is a
different problem from a memory-delivery bug and not what this issue describes.
Apologies for the noise. Closing is appropriate unless the maintainers want to keep it open for the
narrower observation that sessions cannot reliably self-report whether their memory index was injected —
which is arguably worth surfacing in the product, since it is what made this so hard to diagnose.