›_ Claude Code Issues
Claude Code Issues / #55676

[BUG] macOS auto-memory scoped to home-dir hash, ignoring cwd-hash dirs

Status Fixed / completed
Reported on v2.1.118
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 3 comments · opened May 2, 2026 · closed May 2, 2026

Environment

  • Claude Code version: 2.1.118 (brew cask) AND 2.1.126 (native installer at ~/.local/bin/claude). Reproduced on both.
  • macOS: Sequoia (Darwin 24.3.0 arm64), Apple Silicon Mac mini
  • Cross-reference Linux: Same architecture works correctly on Linux (Ubuntu 24.04 / Claude Code 2.1.122 native installer)

Expected behavior (per docs)

Auto-memory is cwd-keyed: when CC runs at <cwd>, it reads/writes ~/.claude/projects/<cwd-with-/-replaced-by-->/memory/. Different cwds get different memory dirs. Documented as platform-agnostic.

Actual behavior on macOS

Auto-memory is keyed only to the user's HOME-dir hash, regardless of cwd. CC at /Users/leofloa/utopia, /Users/leofloa/medumio, or ~ all read/write the SAME dir: ~/.claude/projects/-Users-leofloa/memory/. The cwd-specific hash dirs are never used for memory (only for session JSONLs).

Reproduction

  1. Pre-create a memory file outside CC at the cwd-specific path:

```bash
mkdir -p ~/.claude/projects/-Users-leofloa-utopia/memory
cat > ~/.claude/projects/-Users-leofloa-utopia/memory/MEMORY.md <<'EOM'

  • Test sentinel: the festival mascot is a gardener gnome named Gertrude

EOM
```

  1. Start CC at the matching cwd:

``bash
cd ~/utopia && claude
``

  1. Without invoking /recall, ask Claude: "What's the festival mascot for the sync test?"
  1. Expected: "Gertrude" (loaded from MEMORY.md at the cwd-hash path)
  1. Actual: "I don't have any record of a Utopia festival mascot — nothing in MEMORY.md, the Utopia CLAUDE.md, or the agent vault references one."

Confirming via CC's own write path

Step 1: at /Users/leofloa/utopia, prompt Claude remember this: utopia mascot is Gertrude. save to memory.

Step 2: Claude responds "Saved to utopia_sync_test_mascot.md and indexed under Project in MEMORY.md."

Step 3: Check filesystem:

  • File DOES NOT appear at ~/.claude/projects/-Users-leofloa-utopia/memory/ (the cwd-hash dir, where it should land)
  • File DOES appear at ~/.claude/projects/-Users-leofloa/memory/utopia_sync_test_mascot.md (the home-dir, where it should NOT land for a ~/utopia cwd)

So even when CC itself writes (the canonical write path), it goes to home-dir hash on macOS.

Cross-platform comparison

On Linux at /home/vbox/medumio, CC correctly uses /home/vbox/.claude/projects/-home-vbox-medumio/memory/. Past session JSONLs at ~/.claude/projects/-home-vbox-medumio/*.jsonl reference loading the cwd-hash path's feedback_*.md files dozens of times. Linux behavior matches the docs.

Things ruled out

  1. Project registration: Adding /Users/leofloa/utopia (and all life-domain cwds) as entries under the projects key in ~/.claude.json, mirroring the Linux machine's structure. No effect.
  2. CC version: Tested on 2.1.118 (brew) and upgraded to 2.1.126 (native). Same behavior on both.
  3. Permissions: Both the cwd-hash dir and the home-hash dir have identical 755/644 permissions on macOS.
  4. File format: MEMORY.md content is valid markdown matching the format that loads correctly on Linux.

Impact

This breaks per-project memory scoping on macOS — all projects share one memory blob, mixing unrelated domain context. For users with multiple distinct project areas under one HOME (typical), it makes auto-memory effectively unusable as a per-context tool.

Hypothesis

Likely a path-normalization or HOME-stripping bug in macOS-specific slug generation. The slug encoding (replace / with -) appears to collapse the cwd to the home-dir prefix on macOS only.

View original on GitHub ↗

3 Comments

okabadayi · 5 months ago

Update: project-level workaround tested, also doesn't work

After filing this, tried a workaround using project-level .claude/settings.json to override autoMemoryDirectory per-cwd. The setting does work at user-level (~/.claude/settings.json) — verified by setting autoMemoryDirectory: ~/.claude/memory-test-tilde there and confirming Claude Code wrote a memory file at the configured path. But at project level it's silently ignored.

Reproduction

  1. Set up project-level override:

``bash
cd ~/medumio
mkdir -p .claude
cat > .claude/settings.json <<'JSON'
{"autoMemoryDirectory": "~/.claude/memory-medumio"}
JSON
mkdir -p ~/.claude/memory-medumio
``

  1. Run CC at the cwd:

``bash
claude
``

  1. In CC: prompt to save a sentinel:

> save to memory: testing project-level settings — sentinel CherryPie

  1. CC reports it saved successfully. But the file actually lands at ~/.claude/projects/-Users-leofloa/memory/project_settings_test_sentinel.md (the home-dir hash dir, the same broken location from the original bug), not at ~/.claude/memory-medumio/ as the project-level setting requested.

Implication

The two combined behaviors mean per-cwd memory routing is fully broken on macOS: the default cwd-hash mechanism doesn't work (original bug), and the per-project override mechanism is also silently ignored. Users with multiple distinct project areas under one HOME effectively can't keep memories scoped per-project.

Tested versions

  • Claude Code 2.1.118 (brew cask)
  • Claude Code 2.1.126 (native installer at ~/.local/bin/claude)

Both produce the same behavior. Linux at the same versions correctly honors both cwd-hash AND project-level settings — confirmed empirically.

Question (not requesting an answer here, just for issue completeness)

Is project-level autoMemoryDirectory intentionally not honored as a security measure (preventing untrusted project dirs from redirecting memory)? If so, that warrants a doc note. If not, this is a second related bug.

okabadayi · 5 months ago

Closing — this is not a bug, it's expected behavior I misunderstood.

Per the official memory docs: "Each project gets its own memory directory at ~/.claude/projects/<project>/memory/. The <project> path is derived from the git repository, so all worktrees and subdirectories within the same repo share one auto memory directory."

What I observed on macOS was correct: /Users/leofloa/medumio, /Users/leofloa/utopia, etc. were all subdirectories of one git repository (a parent vbox repo containing all life domains). Claude Code correctly derived their project root as the parent repo and routed memory to the parent's slug dir. I just misread it as a per-cwd hash.

Verified the same behavior on Linux (claude -p at /home/vbox/medumio writes to ~/.claude/projects/-home-vbox/memory/, the vbox repo root, not -home-vbox-medumio/memory/ which only exists as legacy from when medumio was a separate repo before May 1, 2026).

So both platforms behave per docs. No bug. Apologies for the noise.

The earlier comment about project-level autoMemoryDirectory not being honored at project scope (only user scope) — separate concern, but if you'd like that as its own report I can file it cleanly.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →