[BUG] Fresh CLI-only install wedges on auto-created 'main': config says it exists, DB says it doesn't (regression of #974)

[oliver-mee]

Bug Description

On a brand-new install, a CLI-only flow wedges on the auto-created main project. config.json contains main and default_project: "main", but the project table has no matching row, so every default-project code path fails.

The two error messages contradict each other, and the advice in one of them is the command that cannot work:

• bm project add main <path> fails with Project 'main' already exists (config check)
• bm status, bm project remove main, and every bm tool ... call fail with Project not found: 'main'. No projects are set up yet — run 'basic-memory project add <name> <path>' to create one (database check)

This is a regression of #974, which was closed as completed on 2026-06-12. The root cause note in that issue still describes what I see: reconciliation happens on a path a CLI-only flow never hits. I confirmed that starting the MCP server once does create the row, after which the CLI works normally.

Steps To Reproduce

Isolated environment, so it does not touch an existing install:

export HOME=$(mktemp -d)
export BASIC_MEMORY_CONFIG_DIR=$(mktemp -d)

bm project list                          # shows 'main' as default
bm project add main "$HOME/basic-memory" # Error: Project 'main' already exists
bm status                                # Error: Project not found: 'main'. No projects are set up yet...

Pre-creating $HOME/basic-memory makes no difference. Note that #974's repro reaches the same wedged state by adding a differently named project first; here it happens with no successful project add at all.

Starting the server once repairs it:

timeout 20 bm mcp --transport streamable-http --port 8899
bm status                                # now works: "main: Project Index / 0 observed files"

Expected Behavior

Either the CLI bootstraps the auto-created default project into the database on first use, or project add main <path> reconciles the existing config entry instead of refusing. A new user following the CLI quickstart should not reach a state where the only escape is to pick a different project name.

Actual Behavior

$ bm project list
│ main │ ~/basic-memory │ │ │ local │ stdio │ │ [X] │

$ bm project add main "$HOME/basic-memory"
Error adding project: Project 'main' already exists

$ bm status
Error: Project not found: 'main'. No projects are set up yet — run 'basic-memory
project add <name> <path>' to create one.

$ bm project remove main
Error removing project: Project not found: 'main'. No projects are set up yet — run
'basic-memory project add <name> <path>' to create one.

The database confirms the split: select name from project returns no rows while config.json lists main under projects with default_project: "main".

Adding a project under any other name succeeds and works fine, which is the workaround.

Environment

• OS: Ubuntu 24.04 (aarch64)
• Python version: 3.14 (uv tool environment)
• Basic Memory version: 0.23.2
• Installation method: uv tool install basic-memory
• Claude Desktop version (if applicable): N/A, reproduced from the CLI alone

Additional Context

Clearing projects in config.json by hand does not help, because the entry is re-seeded on the next config load, so project add main still sees it as existing.

I first hit this on 0.23.0 and re-confirmed it on 0.23.2 after uv tool upgrade.

Possible Solution

#974 suggests the shape: reconcile the auto-created default into the project table on the CLI path too, rather than only on server or sync startup. Failing that, making project add treat a config-only entry as repairable rather than a conflict would resolve the deadlock on its own, and would also fix the misleading error text.

Happy to open a PR if you can point me at the preferred place for that reconciliation.