Block rclone sync/bisync commands for Team workspaces with clear errors

[groksrc]

Feature / UX Request

Make cloud rclone sync/bisync commands explicitly Personal-workspace-only and block Team/organization workspaces with a clear error.

Team/organization workspaces cannot safely use rclone bisync as a multi-user local mirror. The CLI should make this constraint explicit anywhere users might attempt sync setup or sync execution.

Commands to Review

• bm cloud sync-setup
• bm cloud sync
• bm cloud bisync
• bm cloud check
• bm cloud bisync-reset

Expected Behavior

When the target project belongs to a Team/organization workspace, commands should exit before invoking rclone and print a clear message such as:

Local rclone sync/bisync is supported only for Personal workspaces.
Team workspaces are accessed through the cloud API/MCP and do not support local multi-user bisync.
Use `bm project list --workspace <workspace>` to inspect Team projects.

Actual Behavior

The project listing suppresses sync for Team/organization rows, but the cloud sync/bisync command help and command flow do not clearly state or enforce that Team workspaces are unsupported.

Motivation

Without an explicit block, users and agents may assume a Team workspace can be configured with a local sync path and may attempt unsafe or unsupported rclone workflows.

Acceptance Criteria

• Sync/bisync commands resolve the target workspace/project unambiguously before setup/execution.
• Team/organization targets produce a clear unsupported-workspace error.
• Personal workspace sync/bisync behavior remains unchanged.
• Command help documents the Personal-workspace-only limitation.

[claude]

Claude finished @groksrc's task in 9m 37s —— View job

---

Issue Triage & Implementation

Triage:

• Type: Enhancement (improvement to existing cloud CLI feature)
• Priority: Medium — without this guard, users/agents may attempt unsafe rclone workflows on Team workspaces
• Component: CLI / Cloud
• Complexity: Medium

---

Changes Made

Two new helpers added to src/basic_memory/cli/commands/cloud/project_sync.py:

• _get_workspace_for_project(name, config) — resolves the WorkspaceInfo for a project by looking up entry.workspace_id in config, falling back to config.default_workspace, then fetching from the /workspaces/ API.
• _require_personal_workspace(name, config) — calls the above and exits with a clear error if the workspace type is "organization".

All 5 affected commands now call _require_personal_workspace before touching rclone:

Command	Guard placement
bm cloud sync	After credential check
bm cloud bisync	After credential check
bm cloud check	After credential check
bm cloud sync-setup	After credential check
bm cloud bisync-reset	Only when credentials are present (reset is harmless without them)

All command docstrings updated to document the Personal-workspace-only limitation.

Error message shown to users:

Local rclone sync/bisync is supported only for Personal workspaces.
Team workspaces are accessed through the cloud API/MCP and do not support local multi-user bisync.
Use 'bm project list --workspace <slug>' to inspect Team projects.

Tests added to tests/cli/cloud/test_project_sync_command.py:

• test_sync_commands_block_organization_workspace — parametrized across all 5 commands, verifies exit code 1 and correct error message
• test_sync_commands_allow_personal_workspace — verifies personal workspace proceeds normally
• test_bisync_reset_skips_workspace_check_without_credentials — verifies bisync-reset works without credentials

---

• Analyze issue and classify
• Explore cloud CLI command implementations
• Locate workspace type detection logic
• Implement _get_workspace_for_project async helper
• Implement _require_personal_workspace guard function
• Add workspace guard to all 5 sync/bisync commands
• Update command docstrings to document Personal-workspace-only
• Add tests for organization workspace rejection
• Add GitHub label (enhancement)
• Push changes — failed: github-actions[bot] token lacks write access to this repo

Note on push failure: Commit 83c9054 exists locally on branch claude/issue-849-20260524-1511 but the GitHub Actions token used by this workflow lacks write access (Permission to basicmachines-co/basic-memory.git denied to github-actions[bot]). A maintainer can cherry-pick or the workflow can be re-run with a token that has contents: write permission.

[phernandez]

@groksrc lets come up with a clear explaination for the docs for this. I think sync is ok, maybe we just make it clear