Removing a cloud project leaves an undeletable local stub that list-projects still returns

[nellins]

Summary

Removing a cloud-routed project can leave behind a local entry that list-projects still returns but bm project remove reports as not found. The name stays permanently occupied — bm project add rejects it as taken, and nothing can delete it.

Reproduce

bm project add openclaw-demo --cloud --workspace "Team Drew"
# → Project 'openclaw-demo' added successfully

bm project remove openclaw-demo
# → Project 'openclaw-demo' deletion queued

The cloud project goes away. A local stub remains:

bm tool list-projects
# → {"name": "openclaw-demo", "source": "local", "cloud_path": null, "local_path": "/"}

Note source has flipped from cloud to local and local_path is /, which is not a path anyone configured.

Now it can't be removed:

bm project remove openclaw-demo
# → Error removing project: Project not found: 'openclaw-demo'

Still in this state hours later, so it isn't the queued deletion catching up.

Impact

The name is burned. This surfaced while preparing a docs video: the project name had to be created on camera, so a stuck entry meant picking a different name and re-recording the setup.

Two things look wrong independently:

1. list-projects and project remove disagree about whether the project exists.
2. Removing a cloud project leaves a local entry pointing at /. Deletion looks like it's converting the record rather than removing it.

Environment

basic-memory 0.23.2, macOS, cloud-routed project in an organization workspace.

[claude]

Claude finished @nellins's task in 33s —— View job

---

Triage

Type: Bug — cloud project removal leaves an orphaned local config entry, and the two commands (bm project remove vs list-projects) disagree about whether the project still exists.

Priority: High — the project name becomes permanently unusable (project add rejects it as taken, project remove reports "not found"), with no documented recovery path other than manual config editing. Not data loss and not affecting core sync, but a full dead-end for the affected project name.

Component: Cloud (per-project cloud routing / local project config) — the repro shows bm project add --cloud, bm project remove on a cloud-routed project, and the local config entry's source field flipping from cloud to local with local_path becoming /. Likely intersects basic_memory/cli/commands/project.py and services/project_service.py, where remove-project logic for cloud-routed entries appears to rewrite the local config record rather than deleting it.

Complexity: Medium — reproduction is clear and deterministic; fix likely involves correcting the remove path for cloud-routed projects so it deletes the local config entry (rather than converting it to a bogus local one) and reconciling list-projects with whatever project remove uses to check existence.

Reproduction: Already clear and complete (exact commands and outputs provided) — no additional repro steps needed.

No duplicate issues found in the tracker.