Cloud upload and API routing don't support workspace selection

[groksrc]

Problem

When using Basic Memory Cloud with multiple workspaces (personal + teams), the bm cloud upload command and several cloud API utility functions don't route requests to the correct workspace. This makes it impossible to upload notes into a teams workspace via the CLI.

Root Cause

Three layers lack workspace support:

1. get_cloud_control_plane_client() in async_client.py — creates an HTTP client for WebDAV upload but doesn't accept or pass the X-Workspace-ID header
2. cloud_utils.py functions (fetch_cloud_projects, create_cloud_project, project_exists) — make API requests without workspace headers, so they always hit the user's personal workspace
3. get_client() per-project routing in async_client.py — when routing a cloud-mode project, doesn't resolve workspace_id from the project config entry or default_workspace

Impact

• bm cloud upload always uploads to the personal workspace even when default_workspace or per-project workspace_id is configured
• --create-project flag creates projects in the wrong workspace
• Post-upload database sync doesn't trigger in the correct workspace

Expected Behavior

• bm cloud upload should resolve workspace from: per-project workspace_id → config.default_workspace → personal (fallback)
• All cloud API utility functions should pass X-Workspace-ID header when a workspace is resolved
• get_client() per-project routing should auto-resolve workspace from project config

Steps to Reproduce

1. Have multiple workspaces (personal + teams)
2. bm cloud workspace set-default <teams-tenant-id>
3. bm project set-cloud myproject --workspace <teams-tenant-id>
4. bm cloud upload ~/myproject --project myproject
5. Files end up in personal workspace, not teams workspace

Environment

• Basic Memory v0.20.3
• Multiple cloud workspaces configured

[claude]

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

---

Issue Triage

• Gather context and read issue
• Analyze relevant source files
• Check for duplicate issues
• Apply labels and provide triage summary

---

Analysis

Type: Bug report — existing cloud workspace functionality is incomplete/missing across multiple layers

Priority: High — breaks multi-workspace cloud usage (teams use case), which is a core cloud feature

Components: Cloud, CLI

Complexity: Medium — the infrastructure partially exists but needs wiring through multiple layers

---

Root Cause Confirmed

After reading the relevant source files, I can confirm the three-layer gap the reporter identified:

1. get_cloud_control_plane_client() (async_client.py:91-102)
No workspace parameter accepted or X-Workspace-ID header passed, despite the underlying _cloud_client() helper already supporting it (lines 70-87).

2. cloud_utils.py (fetch_cloud_projects, create_cloud_project, project_exists)
All three functions call make_api_request without any workspace header. They read config.cloud_host but never read config.default_workspace.

3. get_client() per-project routing (async_client.py:178-195)
When routing a cloud-mode project, _cloud_client(config, timeout, workspace=workspace) is called — but workspace must be explicitly passed by the caller. The function never auto-resolves it from the project's workspace_id config field (config.py:102) or config.default_workspace (config.py:401).

No duplicate issues found — this is a new report.

---

Labels Applied

bug, cloud

---

Suggested Fix Approach

The fix would involve three targeted changes:

1. get_cloud_control_plane_client() — add optional workspace: str | None = None param and pass it as X-Workspace-ID header
2. cloud_utils.py — resolve workspace via config.default_workspace and pass it through api_request headers
3. get_client() per-project routing — when project_name is provided and mode is CLOUD, resolve workspace from project config's workspace_id → config.default_workspace before calling _cloud_client()

The resolution chain should be: per-project workspace_id → config.default_workspace → no header (personal workspace fallback)