CLAUDE_CONFIG_DIR does not fully isolate user-level CLAUDE.md discovery from $HOME/.claude
Description
When running Claude Code with CLAUDE_CONFIG_DIR set to a directory other than$HOME/.claude (e.g. to maintain two fully separate profiles — "work" and
"personal" — on the same machine), the session still appears to pick up$HOME/.claude/CLAUDE.md (the default location) as a user-level memory
source, even though that path is outside the configured CLAUDE_CONFIG_DIR.
This breaks the expectation that CLAUDE_CONFIG_DIR fully isolates a profile's
settings, memory, and credentials from the default one.
Setup
Two shell aliases for two fully separate profiles:
alias claude-work="~/.local/bin/claude"
alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal ~/.local/bin/claude"
~/.claude/CLAUDE.md(work profile) contains an@importline pointing to
a work-only file:
@/path/to/work-org-standards/.claude/CLAUDE.md
~/.claude-personal/CLAUDE.mddoes not exist at all.- No project-level
CLAUDE.mdexists anywhere on the path from/down to the
personal project directory being used.
Repro
cd ~/personal/some-project(a project with no CLAUDE.md anywhere in its
path, unrelated to the work profile).
- Run
claude-personal(i.e.CLAUDE_CONFIG_DIR=~/.claude-personal claude). - Claude Code shows:
> Allow external CLAUDE.md file imports?
> This project's CLAUDE.md imports files outside the current working directory.
> External imports:
> /path/to/work-org-standards/.claude/CLAUDE.md
Expected
With CLAUDE_CONFIG_DIR=~/.claude-personal and no CLAUDE.md under that
config dir, no external-import prompt should appear at all — there is no
CLAUDE.md in scope for this profile that contains an @import.
Actual
The prompt appears, referencing an @import line that only exists in~/.claude/CLAUDE.md (the default, non-configured location). This means
the personal profile is reading the work profile's global CLAUDE.md despiteCLAUDE_CONFIG_DIR pointing elsewhere — confirmed by grepping the entire
filesystem: the exact import string only exists in ~/.claude/CLAUDE.md.
Approving the prompt would load the work org's internal engineering standards
document into a personal, unrelated project's context — i.e. cross-profile
context leakage.
Environment
- Claude Code version: 2.1.218
- OS: macOS (Darwin 25.5.0)
- Install method: native binary via version symlink
(~/.local/bin/claude -> ~/.local/share/claude/versions/2.1.218)
Additional notes
Searching strings in the compiled binary shows a literal, non-configurable
reference to ~/.claude/CLAUDE.md (using the real home directory, notCLAUDE_CONFIG_DIR) among candidate context files — consistent with this
being a hardcoded fallback rather than a config resolution bug.
3 Comments
Confirmed this is an issue on Linux as well, on the same Claude Code version.
#79233 might be related.
Reproduced on the current release (2.1.233, Linux) with your exact setup:
CLAUDE_CONFIG_DIRpointing at a separate profile dir containing noCLAUDE.md, no projectCLAUDE.mdanywhere, and~/.claude/CLAUDE.mdcontaining an external@import— the external-imports approval dialog appears listing the work-profile import, and after approval both files load into context.One clarifying detail from testing: this isn't the user-memory lookup ignoring
CLAUDE_CONFIG_DIR. With the same setup but the project located outside the home directory,~/.claude/CLAUDE.mdis not read at all, and aCLAUDE.mdplaced inside the configured dir loads correctly — so user-scope memory does followCLAUDE_CONFIG_DIR.What's biting you is the parent-directory discovery: Claude Code loads
CLAUDE.md/.claude/CLAUDE.mdfrom every directory above the working directory (see https://code.claude.com/docs/en/memory). When your project lives under your home directory — as~/personal/some-projectdoes —~/.claude/CLAUDE.mdmatches the<ancestor>/.claude/CLAUDE.mdpattern and is picked up as an ancestor project file, independent of the configured profile dir. That's why moving the config dir doesn't stop it, and it confirms the cross-profile leakage you describe: the "work" file effectively becomes visible to every profile whose projects sit under$HOME.We agree this defeats the isolation
CLAUDE_CONFIG_DIRis meant to provide, so keeping this open. Workarounds in the meantime:claudeMdExcludesin the personal profile's settings, e.g."claudeMdExcludes": ["/Users/you/.claude/CLAUDE.md"], or~/.claude/CLAUDE.mditself.🤖 Generated with Claude Code