[BUG] bm project list only resolves one workspace — Workspace column empty and cross-workspace projects missing

[groksrc]

Bug Description

bm project list makes two related mistakes when discovering cloud projects: (a) it only fetches projects from a single workspace (the one named by --workspace or config.default_workspace), silently omitting projects in any other workspace the user has access to, and (b) the Workspace column in the resulting table is empty for every row unless that single workspace was explicitly specified.

Both symptoms stem from the same code path in src/basic_memory/cli/commands/project.py:list_projects, which assumes there is exactly one workspace to consider.

Steps To Reproduce

1. Install Basic Memory from current main (uv tool install --editable .)
2. Have access to one or more cloud workspaces
3. Do not pass --workspace, and do not have default_workspace set in ~/.basic-memory/config.json
4. Run bm project list

Expected Behavior

• Projects from all workspaces the user has access to are listed
• The Workspace column is populated for every cloud-sourced row, indicating which workspace owns the project

Actual Behavior

• Only projects from the default/specified workspace appear; projects in other workspaces are silently missing
• The Workspace column is empty for every row

Environment

• OS: macOS 15.7.2 (Darwin 24.6.0)
• Python version: 3.14.2
• Basic Memory version: 0.20.4.dev75+c6fa185b (HEAD c6fa185b on main; note __version__ string still reads 0.20.3)
• Installation method: uv tool install --editable .

Additional Context

Source analysis at src/basic_memory/cli/commands/project.py:323-510:

Bug 1 — Workspace column always empty. Lines 369-386 only resolve cloud_ws_name when effective_workspace is truthy:

if cloud_result and effective_workspace:
    ...
    matched = next(
        (ws for ws in workspaces if ws.tenant_id == effective_workspace),
        None,
    )
    if matched:
        cloud_ws_name = matched.name

With no --workspace and no default_workspace in config, effective_workspace is None, so cloud_ws_name stays None and the row-building code at line 462 never sets ws_label.

Bug 2 — Single-workspace cloud fetch. Line 365:

cloud_result = run_with_cleanup(_list_projects(effective_workspace))

calls the cloud list endpoint with a single workspace identifier. There's no iteration over get_available_workspaces(), so projects from any other workspace the user can access are silently excluded.

Possible Solution

Have list_projects iterate over get_available_workspaces(), call _list_projects(ws.tenant_id) per workspace, and label each row with the originating workspace name/type. The existing dedup-by-permalink logic would need to either be removed (workspace becomes part of the row identity) or extended to key on (workspace, permalink) so the same project name in two workspaces isn't collapsed.

[claude]

Claude finished @groksrc's task in 13m 37s —— View job • claude/issue-820-20260514-0206 • Create PR ➔

---

Fix Implemented

• Analyze issue and classify
• Read relevant source code (project.py)
• Implement fix for Bug 1 (Workspace column empty)
• Implement fix for Bug 2 (Single-workspace cloud fetch)
• Add/update tests
• Apply labels (bug)
• Push changes and create PR

Classification:

• Type: Bug
• Priority: High — cloud projects silently missing, workspace column always empty
• Component: CLI, Cloud
• Complexity: Medium

Root cause:
Both bugs stem from list_projects in src/basic_memory/cli/commands/project.py.

• Bug 1: workspace name was only resolved when effective_workspace was truthy (line 372 in original). With no --workspace flag and no default_workspace in config, the Workspace column stayed empty.
• Bug 2: a single _list_projects(effective_workspace) call with no iteration over available workspaces meant projects from any workspace beyond the default were silently dropped.

Fix:
Introduced _fetch_cloud_workspace_results(), an inner helper that:

1. Calls get_available_workspaces() to retrieve all workspaces the user has access to
2. If a specific workspace was requested (--workspace / default_workspace), fetches only that one but still carries its WorkspaceInfo object for labeling
3. Otherwise iterates every available workspace and fetches projects from each
4. Returns (WorkspaceInfo | None, ProjectList) pairs — the workspace object is attached at fetch time so row-building never needs a separate resolution pass
5. Falls back gracefully (empty workspace label, un-scoped fetch) if get_available_workspaces() fails

Row-building was restructured to produce one row per (workspace, permalink) pair, so projects from multiple workspaces all appear with their workspace labeled correctly.

Tests added:

• test_project_list_workspace_column_populated_without_explicit_workspace — verifies Bug 1 fix
• test_project_list_fetches_from_all_workspaces — verifies Bug 2 fix
• Updated mock_client fixture to also mock get_available_workspaces (avoids real API calls in existing tests)

|