autoMemoryDirectory silently ignored when set in settings.local.json (works via --settings flag)

Claude Code Bug — autoMemoryDirectory ignored when set in settings.local.json

Version: 2.1.126
Platform: macOS (Darwin 25.3.0), zsh
Date: 2026-05-03
Reporter context: discovered during a teaching session investigating why a custom auto-memory directory wasn't loading at session start.

Summary

autoMemoryDirectory set in .claude/settings.local.json (the local settings layer) is silently ignored — the platform falls back to the default ~/.claude/projects/<munged>/memory/ path. The identical JSON value passed via the --settings flag (inline OR via a settings file) IS honored.

Smoking gun: autoMemoryEnabled: false in the SAME settings.local.json file IS honored (probe confirms auto-memory disables correctly when the key is added there). So the local layer reads autoMemoryEnabled from this file but silently skips autoMemoryDirectory. This rules out a layer-loader bug and pins the regression on per-key consumption logic in the auto-memory module: autoMemoryDirectory is being filtered out for the local source despite the docs saying it should accept it.

Reproduction

1. In any project, create .claude/settings.local.json containing (only relevant key shown):

``json
{ "autoMemoryDirectory": "/absolute/path/to/custom-memory-dir" }
``

1. Run:

``bash
claude --print "Reply with the literal path of your current auto memory directory and nothing else."
``

1. Claude reports the default platform path, NOT /absolute/path/to/custom-memory-dir.

Expected

Claude reports the value of autoMemoryDirectory from settings.local.json. Per the docs (code.claude.com/docs/en/memory.md):

This setting is accepted from policy, local, and user settings.

Actual

Claude reports the platform default. No log message, no warning, no error.

Confirmed working alternative (workaround)

The same JSON, delivered via the --settings flag, IS honored:

# Inline JSON
claude --print --settings '{"autoMemoryDirectory":"/absolute/path"}' "..."
# → Claude reports the custom path correctly

# Via a settings file
echo '{"autoMemoryDirectory":"/absolute/path"}' > /tmp/test.json
claude --print --settings /tmp/test.json "..."
# → Claude reports the custom path correctly

So the value is parseable, validated, and applied by Claude Code — but only when delivered via --settings, not via the local settings-file layer.

Test matrix (full run)

| Delivery | Path value | Claude reports | Verdict |
|---|---|---|---|
| Control (no override) | — | platform default | settings.local.json's value not applied |
| --settings inline | /tmp/cc-mem-test (absolute, no space) | /tmp/cc-mem-test/ | ✓ honored |
| --settings inline | /tmp/cc mem test (absolute, with space) | /tmp/cc mem test/ | ✓ honored — spaces fine |
| --settings inline | agents/memory (relative) | platform default | ✗ silently rejected (separate UX issue) |
| --settings inline | ~/test-mem-tilde (tilde) | /Users/.../test-mem-tilde/ | ✓ honored, expansion works |
| --settings <file> | absolute path with project's space | absolute path with space | ✓ honored |
| .claude/settings.local.json | absolute path with project's space (literal) | platform default | ✗ silently ignored |
| .claude/settings.local.json | tilde-form absolute | platform default | ✗ silently ignored |
| .claude/settings.local.json | (different key) "autoMemoryEnabled": false | auto-memory disables | ✓ honored — proves the local layer IS read; the bug is per-key for autoMemoryDirectory |

Ruled-out causes

• Path contains spaces — not the cause (inline-JSON test with space worked).
• Relative path — was the original setting in this user's case; now fixed to absolute, but the issue persists.
• Tilde expansion — works via inline JSON; fails via any file-load (probable separate issue).
• Workspace trust gating — hasTrustDialogAccepted: false in per-project state in ~/.claude.json, but opening claude interactively in the project did not trigger a trust dialog and did not change probe result.
• Higher-precedence override — no autoMemoryDirectory in user settings, project settings, global ~/.claude.json, or per-project state.
• JSON validity — file parses cleanly; node -e '...' confirms key and value as expected.
• Setting source filter — explicitly running claude --print --setting-sources user,project,local produced the same default-path result.

Suggested fix

Audit the auto-memory module's settings-consumption logic. Two divergences to investigate:

1. Per-key divergence within the local layer — autoMemoryEnabled is read; autoMemoryDirectory is silently skipped. Same file, same layer, adjacent keys.
2. Per-source divergence for autoMemoryDirectory — --settings flag works (inline + file); local-layer settings.local.json doesn't. Different load paths converging on the same module.

Together these suggest autoMemoryDirectory has a narrower per-source allowlist than autoMemoryEnabled does — and that allowlist excludes the local source despite the docs (code.claude.com/docs/en/memory.md) saying "This setting is accepted from policy, local, and user settings."

Related minor UX issues (separate, but worth filing alongside)

1. Relative paths for autoMemoryDirectory are silently rejected (no log, no warning, falls back to default). Suggest emitting at minimum a debug-log warning, ideally a startup-visible warning, when a non-absolute path is provided.
2. Tilde expansion behaves inconsistently across delivery paths. Works via --settings inline JSON; appears to fail when the same ~/... value is loaded from any settings file. Documenting the actual supported value formats per delivery surface would help.

Environment summary

• Claude Code: 2.1.126
• Node / OS: macOS Darwin 25.3.0, zsh
• Project root with space in path (/Users/.../AI work/personal-agent) — confirmed not causal but worth noting for repro fidelity
• No managed-policy CLAUDE.md or settings overrides (/Library/Application Support/ClaudeCode/ does not exist)
• User-level settings (~/.claude/settings.json) contains no autoMemory* keys
• Per-project state in ~/.claude.json contains no autoMemory* keys

Steps the reporter took before filing

Verified the value is correct, the file is valid JSON, the layer is documented as accepted, and that the platform applies the same value when delivered via --settings. Ruled out user-side causes systematically before concluding it's a platform-side issue.