CLAUDE_CONFIG_DIR does not fully isolate user-level CLAUDE.md discovery from $HOME/.claude

Status Open
Reported on v2.1.218
Maintainer reply ✓ Yes — bcherny
Activity 3 comments · opened Jul 23, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

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 @import line pointing to

a work-only file:
@/path/to/work-org-standards/.claude/CLAUDE.md

  • ~/.claude-personal/CLAUDE.md does not exist at all.
  • No project-level CLAUDE.md exists anywhere on the path from / down to the

personal project directory being used.

Repro

  1. cd ~/personal/some-project (a project with no CLAUDE.md anywhere in its

path, unrelated to the work profile).

  1. Run claude-personal (i.e. CLAUDE_CONFIG_DIR=~/.claude-personal claude).
  2. 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 despite
CLAUDE_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, not
CLAUDE_CONFIG_DIR) among candidate context files — consistent with this
being a hardcoded fallback rather than a config resolution bug.

View original on GitHub ↗

3 Comments

rvalles · 1 month ago

Confirmed this is an issue on Linux as well, on the same Claude Code version.

rvalles · 1 month ago

#79233 might be related.

bcherny collaborator · 5 days ago

Reproduced on the current release (2.1.233, Linux) with your exact setup: CLAUDE_CONFIG_DIR pointing at a separate profile dir containing no CLAUDE.md, no project CLAUDE.md anywhere, and ~/.claude/CLAUDE.md containing 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.md is not read at all, and a CLAUDE.md placed inside the configured dir loads correctly — so user-scope memory does follow CLAUDE_CONFIG_DIR.

What's biting you is the parent-directory discovery: Claude Code loads CLAUDE.md / .claude/CLAUDE.md from 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-project does — ~/.claude/CLAUDE.md matches the <ancestor>/.claude/CLAUDE.md pattern 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_DIR is meant to provide, so keeping this open. Workarounds in the meantime:

  • Add the file to claudeMdExcludes in the personal profile's settings, e.g. "claudeMdExcludes": ["/Users/you/.claude/CLAUDE.md"], or
  • Keep the shared/work instructions in an imported file rather than ~/.claude/CLAUDE.md itself.

🤖 Generated with Claude Code