bm cloud setup silently overwrites an existing rclone remote (and leaks the prior key)

[phernandez]

Problem

bm cloud setup [--workspace X] overwrites the target rclone remote with freshly minted credentials without warning. Two concrete hazards, both seen during live testing of #920:

1. Silent clobber of a shared remote. A workspace with is_default=True maps to the shared basic-memory-cloud remote (remote_name_for_workspace). Running bm cloud setup --workspace <default-org> silently repointed basic-memory-cloud from one tenant's key to another (tid_qAoENp… → tid_pHBhtF…). If that remote was serving a different tenant, existing sync breaks with no notice. (A backup of rclone.conf is written, but nothing tells the user it changed.)

2. Leaked credentials. For legacy (non-partner-managed) tenants, POST /tenant/mount/credentials mints a new IAM key every call and never revokes the prior one, so each re-setup leaves an orphaned, still-valid key on the tenant's bucket.

Fix (this PR — CLI)

• bm cloud setup aborts if the target rclone remote already exists, unless --force is passed. The check runs before credentials are minted, so an abort mints nothing. Message names the remote and the --force opt-in.

Follow-up (backend, separate)

• Revoke the superseded mount key when re-minting (or have the CLI reuse a stored key), so re-setup doesn't accumulate live keys. Tracked here for the backend (basic-memory-cloud).

Surfaced while testing #920.

[claude]

Claude finished @phernandez's task in 4m 19s —— View job

---

Issue Triage & Implementation

Classification:

• Type: Bug (security/data integrity)
• Priority: High — credential leakage + silent clobber of shared rclone remotes
• Component: CLI, Cloud
• Complexity: Medium

Todos:

• Analyze issue and classify
• Read relevant CLI cloud setup code
• Check for duplicate issues (none found)
• Add labels (bug, cloud)
• Implement --force guard
• Add tests (4 new tests)
• Push branch (blocked by repository permissions for this bot)

---

Implementation

Root cause confirmed: bm cloud setup calls POST /tenant/mount/credentials to mint credentials and then writes them into the rclone config with no check for whether the remote section already exists. Every re-run clobbers the remote silently and leaves an orphaned IAM key.

Fix applied in src/basic_memory/cli/commands/cloud/core_commands.py:

1. Added --force flag to the setup() command
2. Added a guard check after the remote name is resolved but before any network call (Step 2, get_mount_info). This means aborting never triggers credential creation:

# Guard: abort before minting credentials if the remote already exists.
# Trigger: rclone remote already configured for this workspace.
# Why: re-running setup mints a new IAM key on every call and silently
# clobbers the existing remote, which can break other workspaces sharing
# the same remote name and leaves orphaned, still-valid keys on the bucket.
# Outcome: user must pass --force to proceed; no credentials are minted on abort.
if rclone_remote_exists(remote_name) and not force:
    console.print(
        f"\n[red]rclone remote '{remote_name}' already exists.[/red]"
        f"\nPass [bold]--force[/bold] to overwrite it."
    )
    raise typer.Exit(1)

4 new tests in tests/cli/cloud/test_cloud_setup_command.py:

• test_setup_aborts_if_remote_exists — exit code 1 when remote exists, no --force
• test_setup_shows_remote_name_in_abort_message — abort message names the blocking remote
• test_setup_proceeds_with_force_when_remote_exists — --force bypasses the guard
• test_setup_proceeds_when_no_remote_exists — normal fresh-install flow unaffected

Note: The backend follow-up (revoking the superseded key when re-minting) is out of scope for this CLI fix, as described in the issue.

Commit: 3c30139 on branch claude/issue-922-20260608-2302

Push blocked: The GitHub Actions bot does not have write access to push this branch. A maintainer can push or merge the commit manually.