fix(cli): honour CLAUDE_CONFIG_DIR when resolving Claude hook settings

[fzipi]

Fixes #1418.

What this does

_claude_user_dir() resolves the user-level Claude config directory from CLAUDE_CONFIG_DIR, falling back to ~/.claude when it is unset or blank. Both places that previously hardcoded Path.home() / ".claude" now use it:

• load_claude_settings() — the user-level basicMemory base.
• _hook_config_path() — the hook install / hook remove target.

Claude Code treats CLAUDE_CONFIG_DIR as a full replacement for ~/.claude, so with per-account profiles the old behaviour meant a profile's basicMemory block was never read (hook status printed settings: not found, capture fell back to the default project), and hook install wrote hook entries into a different profile's settings file.

One subtlety worth reviewing

_claude_project_dir() walks ancestors, and that walk can reach $HOME and match ~/.claude/settings.json. The old code suppressed that with if project != home. Comparing only the new profile dir is not enough — with CLAUDE_CONFIG_DIR pointing elsewhere, ~/.claude no longer equals the user dir, so it re-enters as a project-level source and outranks the active profile. Both guards are kept:

if project != Path.home() and project_dir != user_dir:

test_claude_config_dir_ignores_default_home_settings covers exactly this; it fails with only the profile-dir comparison in place.

Behaviour when CLAUDE_CONFIG_DIR is unset

Unchanged. _claude_user_dir() returns ~/.claude, and the retained project != Path.home() guard preserves the original precedence, including the malformed-file fail-closed path.

Tests

Seven added in tests/cli/test_hook_command.py: profile settings are read; the default profile's settings do not leak in; project settings still win over a profile block; blank and whitespace values fall back to ~/.claude; ~ is expanded; hook install writes into the profile dir and leaves ~/.claude untouched; hook remove cleans up there.

tests/cli/conftest.py::isolated_home now clears CLAUDE_CONFIG_DIR, so a contributor running the suite under a profile wrapper does not have tests read their real config.

Verified the new tests fail without the source change (6 of 8 fail; the two blank-value cases assert fallback behaviour that already held). tests/cli passes in full — 937 tests. ruff check, ruff format --check, and ty check src tests test-int are clean; the 4 pymilvus unresolved-import diagnostics are pre-existing on main and unrelated.

Note on Codex

~/.codex is left alone. CODEX_HOME would be the equivalent knob, but that is a separate change and I did not want to widen this one.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: acdb2ad346

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Keep local overrides when the profile overlaps the project

When CLAUDE_CONFIG_DIR points to the current project's .claude directory—a valid way to create a repo-specific Claude profile—project_dir == user_dir makes this branch skip both project sources. Although deduplicating settings.json is appropriate, the distinct settings.local.json must still be merged; otherwise its higher-precedence primaryProject or capture settings are ignored and hooks can route notes to the profile-wide project instead. Deduplicate the individual settings.json path while retaining settings.local.json.

AGENTS.md reference: AGENTS.md:L393-L393

Useful? React with 👍 / 👎.

[fzipi]

Good catch — confirmed and fixed in 54df21f.

I reproduced it before changing anything: with CLAUDE_CONFIG_DIR set to the project's own .claude directory, settings.local.json was dropped entirely and primaryProject fell back to the profile-wide value.

The fix deduplicates by resolved file path rather than by directory, so settings.json is read once as the user-level source while settings.local.json still layers on top:

if project != Path.home():
    project_dir = project / ".claude"
    seen = {path.resolve() for path in sources}
    for name in ("settings.json", "settings.local.json"):
        path = project_dir / name
        if path.resolve() not in seen:
            sources.append(path)

resolve() matters on macOS, where the project path is already resolved but the env value may not be.

Covered by test_claude_config_dir_pointing_at_project_keeps_local_override, which fails without the change. The project != Path.home() guard is kept, so ~/.claude/settings.local.json is still not read as a project source when the ancestor walk reaches $HOME — that is pre-existing behaviour and out of scope here.

One note: the cited AGENTS.md:L393 is a glossary entry about knowledge structure and does not relate to settings precedence.