fix(cli): --host cloud targets cloud workspaces instead of an offline host

Merged
KI
7d ago
+130-52

Bug

The API and automation run records report a cloud workspace's host as the string "cloud" (for example superset automations logs shows "hostId": "cloud"). So users and agents run:

superset workspaces update <cloud-ws-id> --host cloud --name "..."

When the cloud sandbox is suspended, this fails with Error: Host is not online. resolveWorkspaceHost passed --host cloud through resolveHostFilter as an explicit host id, so the command went to resolveHostTarget and not to the cloud API path (hostId === undefined). For workspaces update, the cloud path calls cloudWorkspace.rename / setTags. These work while the sandbox sleeps, because the name and tags live in the API DB. Calling those procedures directly renamed 9 suspended cloud workspaces. With --host cloud, all 9 failed. Leaving out --host already works.

Fix

resolveWorkspaceHost now returns undefined (the cloud) for --host cloud, in any case. That is the same as the default for accounts with cloud workspaces. --host cloud --local still errors with "Pass either --host or --local, not both", because resolveHostFilter runs first. The --host description on each affected command now mentions cloud.

Callers checked

Direct callers of resolveWorkspaceHost:

  • workspaces get / open: these read the cloud row from cloudWorkspace.list and never wake the sandbox.
  • workspaces list: lists from cloudWorkspace.list. --project and --tag are still refused for cloud.
  • workspaces update: uses cloudWorkspace.rename / setTags. --task-id and --clear-task are still refused for cloud.
  • workspaces archive: uses cloudWorkspace.delete.
  • workspaces create: uses createCloudWorkspace. --environment and --machine-size are now accepted with --host cloud.

Callers through resolveWorkspaceTarget: terminals *, agents create/read/wait/explain, and the session commands (lib/sessions.ts). --host cloud now goes to resolveCloudWorkspaceTarget, the same as the cloud default. Before, it failed as an unknown host. These commands still need the sandbox to be online, as before.

Not changed:

  • workspaces sleep and workspaces description set have no --host.
  • projects list/create/setup, agents list, browser *, panes * and snapshot take a host id with no cloud API path.

Tests

  • New packages/cli/src/lib/cloud-workspaces/resolveWorkspaceHost.test.ts checks three cases: --host cloud / Cloud / CLOUD give undefined, a real host id gives itself, and --host cloud --local throws. The stubbed API throws if it is called. With the fix reverted, the cloud test fails (Received: "cloud").
  • bun test in packages/cli: 477 pass, 0 fail. bun run typecheck: clean. bun run lint:fix: no fixes.

Follow-ups (second commit)

  • automations create/update: --host cloud (any case) now means --cloud. With it, --local, --project and --tag (and --session / --clear-tags on update) are refused, the same as with --cloud. New test resolveCloudAutomationTarget.test.ts; it fails with the change reverted (no splitCloudHost export).
  • cli-reference.mdx: each --host that takes cloud now says so.
  • bun test in packages/cli: 478 pass, 0 fail. bun run typecheck: clean. bun run lint:fix: one format fix, folded in.

Summary by cubic

Fixes --host cloud so it targets cloud workspaces instead of being treated as a host ID, which failed with "Host is not online" when the cloud sandbox is suspended.

  • --host cloud (any case) now resolves to the cloud, matching the default for cloud-enabled accounts, and reuses the shared CLOUD_HOST_ID constant.
  • --host cloud --local still errors; unit tests cover all three cases.
  • automations create/update treat --host cloud as --cloud and refuse --local, --project, --tag (and --session/--clear-tags on update) just as --cloud does.
  • Help text on affected commands and cli-reference.mdx now document cloud as a --host option.

Summary by CodeRabbit

  • New Features
    • CLI host options now document cloud as a supported choice across agent, terminal, workspace, session, and automation commands.
    • --host cloud selects cloud workspaces regardless of capitalization. Automation create and update commands also recognize it as a cloud-mode selection.
    • Automation updates can target cloud; moving an automation there requires an environment or workspace.
    • Host IDs continue to target their corresponding machines, and existing default-host behavior remains unchanged.
  • Bug Fixes
    • Combining cloud host selection with --local now returns an error.