bm project set-cloud leaves stale local project in database and config

[groksrc]

Summary

bm project set-cloud <name> does not fully remove the local project state, leaving the project in a local+cloud hybrid state instead of pure cloud.

Steps to reproduce

1. Have a project main configured as local (with a local path like /Users/me/basic-memory)
2. Run bm project set-cloud main
3. Run bm tool list-projects

Expected

main project should have:

• source: "cloud"
• local_path: null
• No entry in the project table of memory.db pointing to the old local path

Actual

main project shows:

• source: "local+cloud"
• local_path: "/Users/me/basic-memory" (the old local path)
• The project table in memory.db still contains a row with the old local path

The config file (~/.basic-memory/config.json) is updated to "mode": "cloud" but still retains the old "path" value. The database project table is not cleaned up at all.

Workaround

1. Remove the project entry from config.json (or set path to the cloud path)
2. Delete the row from the project table in memory.db:

   DELETE FROM project WHERE name = 'main';

3. Remove the (now empty) local directory if it still exists

After this, bm tool list-projects correctly shows source: "cloud".

Environment

• basic-memory: 0.20.2
• macOS arm64
• Python via uv

[claude]

Claude finished @groksrc's task in 2m 35s —— View job

---

Triage Analysis

• Analyze issue and gather codebase context
• Classify issue type, priority, component, complexity
• Check for duplicate issues (none found)
• Apply labels and provide triage summary

---

Issue Triage

Type: Bug report
Priority: Medium — cloud functionality affected, but a manual workaround exists
Component: CLI (set-cloud command) + Cloud + Database
Complexity: Medium — fix requires cleaning up both the config path field and the local database project table entry

---

Root Cause Analysis

The set-cloud command (in src/basic_memory/cli/commands/project.py:618) only updates the project mode in config.json:

config.set_project_mode(name, ProjectMode.CLOUD)
if resolved_workspace_id:
    config.projects[name].workspace_id = resolved_workspace_id
config_manager.save_config(config)

It does not:

1. Clear the path field from the ProjectEntry in config.json
2. Remove/deactivate the project row from the local project table in memory.db

Because the local database still has the project row, the local API still returns it. The _merge_projects() function in src/basic_memory/mcp/tools/project_management.py:83 then sees the project in both local and cloud results and assigns source = "local+cloud" instead of source = "cloud".

---

Fix Required

The set-cloud command should:

1. Remove the project from the local database (or mark it inactive) when switching to cloud mode — so the local API no longer returns it in project listings
2. Optionally clear the path from the ProjectEntry in config, so local_path is properly null

Labels applied: bug, cloud

[phernandez]

Hey @groksrc lets talk about this. I hadn't intended to remove the project state from the local config for cloud. In my mind, you could use either, and the MCP via stdio would use the local. The clis have a --local/--cloud arg override. Maybe that's too confusing though. We should definitely do what is intuitively obvious.

[phernandez]

Hi @groksrc — re-reading this with fresh eyes against current main. The reproduction details are still accurate, but I want to flag a design question before patching, because the "right" cleanup depends on what local+cloud is supposed to mean.

What set-cloud does today

src/basic_memory/cli/commands/project.py:841-894 — only flips mode = cloud and (optionally) sets workspace_id. It deliberately doesn't touch:

• path in the ProjectEntry (config.json)
• the project row in memory.db
• the on-disk note files

…which is what _merge_projects then sees as "this project exists in both sources" → source: "local+cloud".

Two reasonable shapes for the fix

(A) The reporter's expectation: set-cloud is a one-way cutover.
Clear path, drop the DB row, leave the on-disk files alone. After that, the project is purely cloud; set-local would have to re-add a path.

(B) Hybrid is intentional: set-cloud is a routing toggle.
The local copy stays as a passive cache / backup; local+cloud is an honest description, not a bug. Then the fix is in _merge_projects — make the merged project report source: "cloud" when mode == cloud, and keep local_path populated as informational.

The current code reads like (B) was the intent (toggling between modes is reversible, local_path is preserved across the toggle), but the user-visible output reads like (A) was the intent (reporter sees local+cloud as a confusing hybrid state). One of those two stories needs to win.

What would help

Before I patch this, could you confirm which behavior you actually want?

• If (A): set-cloud should also rm the DB row, blank path, and ideally print "your local copy at <path> is no longer tracked by basic-memory" so the user knows to clean it up themselves.
• If (B): I'd rework _merge_projects so cloud-mode projects report source: "cloud" (with local_path retained as cache info) — and set-cloud stays as-is.

I can land either, but I don't want to pick the wrong story. Tagging maintainers for input on intent.

If we go with (A) and you'd like me to draft it, I can; just give the green light.

[phernandez]

Lets do A: the bm project set-cloud ... should update the config and the db state so that the configured state for the project is in the cloud. set-local should do the opposite.

If the cli needs to override behavior, it can pass in the --cloud/--local args.