project add --local-path can write an unloadable config and brick every later bm command

[phernandez]

Summary

bm project add --cloud --local-path <path under a file> persists a config entry whose path cannot be loaded. Every subsequent bm command then dies with "failed to load config" — including the commands a user would reach for to undo it.

Found while implementing #1414 (PR #1440), flagged rather than fixed there because it is a different class from the recovery-path findings that PR was addressing.

Cause

The config save happens before the mkdir. So an invalid --local-path is written to disk first, and the failure that would have revealed it comes second — by which time the bad entry is already persisted.

Why it matters more than it looks

The failure is not scoped to the project that was added. A config that cannot load takes out the whole CLI, so the user has no in-tool route back: they cannot list projects, cannot remove the bad one, and cannot inspect what happened. The recovery is a manual edit of the config file, which the error message does not mention.

Direction

Validate the path before persisting anything, or persist only after the directory exists. Given the ordering is the defect, the second is likely simpler and also fixes any other post-save step that can fail on a path.

Worth checking at the same time:

• Whether config loading should degrade rather than hard-fail on one bad entry, so a single unusable project cannot make the tool unusable. That is arguably the deeper fix — the ordering bug is one way to reach the state, and a hand-edited config is another.
• Whether the same save-before-validate ordering exists on other paths that write config entries.

Verify whether this is pre-existing

PR #1440 restructured the post-persist error handling in this command. Establish whether the save-before-mkdir ordering predates that change — the reporter's reading is that it does, but it should be confirmed against main before the issue is scoped, since that determines whether this is a regression to fix urgently or a long-standing trap.

[claude]

Claude finished @phernandez's task in 1m 54s —— View job

---

Triage

Type: Bug — confirmed by code inspection.

Component: CLI (bm project add) / local config persistence — not Cloud-specific, though it's triggered by --cloud --local-path.

Root cause confirmed, and it's slightly deeper than the report:

• src/basic_memory/cli/commands/project.py:856 calls ConfigManager().save_config(config) with the new ProjectEntry (including the bad local_sync_path) before local_dir.mkdir(parents=True, exist_ok=True) at line 862 — matching the reported ordering bug exactly.
• The reason this actually bricks the CLI: BasicMemoryConfig.ensure_project_paths_exists (src/basic_memory/config_models.py:1048-1073) is a pydantic model_validator(mode="after") that re-runs on every config load and calls path.mkdir(parents=True) for any absolute project path that doesn't exist yet, re-raising on failure. ConfigManager.load_config() (src/basic_memory/config.py:144-150) catches that exception and turns it into raise SystemExit("Error: failed to load config..."). Since nearly every CLI command starts with ConfigManager().config, one bad persisted path takes down the whole tool on the very next invocation — including project list/project remove, which is what a user would reach for to fix it.

Priority: High. Not a security or data-loss issue, but it's a full CLI outage triggered by a single bad flag value, with no in-tool recovery path (matches the issue's own assessment).

Complexity: Medium. The immediate ordering fix (persist only after mkdir succeeds, or validate the path first) is small. The issue's suggested deeper fix — making config load degrade instead of hard-failing on one bad project entry — is a separate, slightly larger design change to ensure_project_paths_exists/load_config, and is worth scoping as a follow-up rather than folding into the same fix.

Verifying "pre-existing" (asked for in the issue): Couldn't be established with certainty in this triage pass — the checkout here is a shallow clone (single commit) and PR-inspection commands (gh pr view/gh pr diff/gh api) weren't available in this environment, so I couldn't diff PR #1440 against its base directly. This is worth confirming by whoever picks up the fix, but doesn't change the triage classification either way since the bug is reproducible on the current code regardless of when it was introduced.

Duplicate check: Searched open issues for related reports (failed to load config, project add local-path, brick) — no duplicates found.

[dawNotPoi]

I reproduced this on the current main: when the local sync path sits below a regular file, the mkdir fails only after the cloud routing entry has been written, and a fresh bm config list then exits while loading that path. I will take the focused ordering fix: create and validate the local directory before mutating or saving config, with a regression test proving the failed add leaves config loadable and later CLI commands usable. I will leave degraded loading of already-bad or hand-edited configs out of scope.