Project with empty path in config.json makes sync adopt the process cwd, mutating unrelated files

[groksrc]

Summary

A project entry in config.json with an empty path (observed with a cloud-mode project: "mode": "cloud", "path": "") is resolved as Path(""), which is cwd-relative. Any process that consumes that project's home (e.g. the sync/watch started by basic-memory mcp) treats whatever directory the process was launched from as the project root — and BM sync then writes frontmatter into every markdown file it finds there.

Observed behavior

While running the retrieval benchmarks (basic-memory-benchmarks), a warm basic-memory mcp stdio server was spawned with the repo as cwd, on a machine whose config.json contained:

"projects": {
  "main": { "path": "", "mode": "cloud", ... }
}

Result: the benchmark repo's own README.md, AGENTS.md, docs/benchmarks.md, and dataset READMEs all got Basic Memory frontmatter injected (title, type: note, permalink: main/...) — i.e. the main project silently adopted the repo as its local root and synced it.

Why it happens

• ProjectConfig is built with home=Path(entry.path) (config.py:775, also :713, :1075). Path("") resolves relative to cwd.
• The ensure_project_paths_exists validator (config.py:779) explicitly skips non-absolute paths ("cloud-only projects whose path is a slug"), so an empty path passes config load without complaint — but downstream consumers of home don't apply the same guard, so the empty path flows through to local sync as cwd.

Repro

1. In config.json, give a project "path": "" (a cloud-mode project in a non-Postgres local install is the natural way this arises).
2. From any directory containing markdown files, start basic-memory mcp and trigger activity.
3. Markdown files in that directory acquire BM frontmatter under the project's permalink namespace.

Proposed fix

Two complementary guards:

1. Validate at load: reject or warn on project entries whose path is empty/relative when they would be used as a local filesystem root (the existing validator already distinguishes absolute vs not — extend that distinction to consumers).
2. Gate local sync by mode: a mode: "cloud" project without an initialized local sync path (bisync_initialized: false, local_sync_path: null) should never be locally synced at all, regardless of what path contains.

Happy to take this one — found it while benchmarking, and the benchmarks repo now isolates itself via BASIC_MEMORY_CONFIG_DIR (basic-memory-benchmarks#14), but the underlying footgun lives here.

🤖 Generated with Claude Code

[claude]

Claude finished @groksrc's task in 1m 40s —— View job

---

Issue Triage

• Gather context and read issue
• Read relevant source files (config.py)
• Check for duplicate issues (no duplicates found)
• Apply labels (bug, cloud)
• Provide triage analysis

---

Analysis

Type: Bug — code defect causing silent, destructive data mutation

Priority: High (borders on critical)
The bug causes unrelated markdown files to be silently mutated (BM frontmatter injected) in whatever directory basic-memory mcp is launched from. It triggers whenever a cloud-mode project has "path": "" in config.json — a natural state after certain cloud setup flows.

Component: Config/cloud/sync pipeline

Complexity: Medium — root cause is well-understood; fix has a clear path

---

Root Cause

Confirmed in source:

1. config.py:713 — get_project_path() returns Path(self.projects[name].path), which is Path("") for an empty path → resolves to cwd.

2. config.py:775 — project_list property constructs ProjectConfig(name=name, home=Path(entry.path), mode=entry.mode) with no guard against empty paths.

3. config.py:791–794 — ensure_project_paths_exists validator correctly skips non-absolute paths with if not path.is_absolute(): continue — but this guard exists only in the path-creation validator, not in any consumer of home.

4. config.py:1075 — get_project_config() also constructs ProjectConfig(name=name, home=Path(entry.path)) without mode awareness, so even cloud-mode projects get a local home that resolves to cwd.

---

Proposed Fix (matches issue author's proposal)

Two complementary guards needed:

1. Validate at load: In ensure_project_paths_exists (and ideally model_post_init), raise a warning or error for projects where path is empty/non-absolute AND mode != "cloud". For cloud-mode projects, home should never be constructed from an empty/relative path — it should be None or raise if a caller tries to use it for local filesystem work.

2. Gate local sync by mode: In the sync/watch startup path, skip project entirely if mode == "cloud" and bisync_initialized == False and local_sync_path is None / empty. The project has no initialized local working directory and should not adopt cwd as a fallback.

---

Labels applied: bug, cloud

[groksrc]

Update: found two more real-world instances of this bug class on the same machine, with significantly larger blast radius. Details sanitized but the mechanics are reproducible.

Instance 2 — direct log confirmation of the empty-path → cwd sync. The active config had a project with "path": "". The log shows it plainly:

basic_memory.sync.sync_service:sync:322 - Sync operation started for directory: . (force_full=False)

Path("") is cwd-relative, so the sync adopted whatever directory the process was launched from and stamped frontmatter into its markdown files.

Instance 3 — a stale project from a previous setup swept an entire code directory. Under a since-changed config state, a project briefly resolved its root to ~/code (a directory of ~25 unrelated git checkouts). One sync pass injected frontmatter into ~1,350 markdown files across ~20 repos, plus non-git files. Long-running MCP servers later re-stamped files, preserving the original (wrong) permalinks on rewrite.

Two observations from the cleanup that raise the severity beyond cosmetic frontmatter:

1. The YAML round-trip can lose content. In at least one file the rewrite dropped the final line of the document body, and in files with existing frontmatter it reformatted unrelated YAML (flow-style lists rewritten as block lists). So an accidental sync is not always cleanly revertible by stripping the added block.
2. Config-dir fallback compounds the problem. Processes spawned with a minimal environment (e.g. MCP stdio servers, which receive a safelisted env that does not include XDG_CONFIG_HOME) silently fall back from the XDG config dir to ~/.basic-memory, so two different config states can be live on one machine at the same time — each with its own opportunity for a bad path. A startup log line naming the resolved config dir + a guard that refuses to sync a root that wasn't explicitly configured as an absolute path would catch both.

The two guards proposed in the issue body would have prevented all three instances.

🤖 Generated with Claude Code

[phernandez]

@groksrc still planning to take this one? No rush — we're sweeping the bug backlog and just want to make sure it doesn't sit unowned. Happy to pick it up if your hands are full with the other PRs in flight.

[groksrc]

Taking a look now..