First `node up` in a fresh directory silently mints a new workspace instead of joining the account's active one

[willwashburn]

Running agent-relay node up in a directory with no pinned workspace key silently creates a brand-new workspace — no prompt, no log line distinguishing "minted" from "joined" — even when the signed-in account already has an active workspace. It should join the account's active workspace or require an explicit choice.

Behavior today

• The mint: crates/broker/src/relaycast/auth.rs:461-464 — when no key candidates resolve, the broker calls create_workspace() unconditionally.
• Fresh directories always mint: deterministic_workspace_name() (auth.rs:258-270) is sha256("{USER}:{cwd}")[..8], so the cwd is in the hash — a fresh directory (or a second clone of the same repo at a different path) always yields a never-seen name and always mints.
• The minted workspace isn't bound to the account: the POST /v1/workspaces call carries no Authorization header.
• Root cause on the CLI side: node up uses a narrower key-resolution chain than other commands. resumePinnedProjectWorkspace (packages/cli/src/cli/lib/broker-lifecycle.ts:1271-1290) checks flag → env → RELAY_NODE_TOKEN → project file, then gives up — it never consults the machine-global store ~/.agentworkforce/relay/workspaces.json (the SDK-backed path in packages/cloud/src/project-workspace-key.ts:109-128 does).
• Silent: no stdin read anywhere in the chain; create_workspace emits no tracing line on success; broker stderr only reaches the user under --verbose. The only signal is the post-hoc Workspace Key: print, identical for minted and joined.
• The 409 name-conflict handler actively avoids joining: auth.rs:659-671 appends a random UUID suffix and mints anyway.
• Enrolled nodes mint too: the fleet-enrollment path (packages/cli/src/cli/commands/node.ts:91-109) sets RELAY_NODE_TOKEN but no workspace key, so an enrolled node — whose enrollment record carries a relayWorkspaceId — still mints a fresh workspace.
• A second mint site re-mints when an env-provided key is rejected 401/403/429 and wasn't an explicit join (auth.rs:538-562).

Expected

Join the account's active workspace when one exists, or stop and require an explicit choice (--workspace-key / interactive confirm on a TTY). Minting should be an explicit act, never a silent default.

Fix seams

• lookup_workspace(name) → GET /v1/workspaces/by-name/{name} already exists in the relaycast crate and is never called from crates/broker/src — the natural join-instead-of-mint hook.
• Consult the machine-global workspace store in the node up resolution chain.
• No workspace-listing capability exists anywhere in packages/cloud/packages/sdk/crates (workspace list reads only the local store) — an account-level list would let the CLI offer a real choice.
• A prompt has to be hoisted into runNodeUp/runUpCommand before startBrokerWithPortFallback and before the --background fork (broker-lifecycle.ts:1310, which detaches with stdio: 'ignore') — the decision currently happens inside the Rust broker child where no TTY interaction is possible.

🤖 Generated with Claude Code

[willwashburn]

Sanitized live capture from the Agent Relay Mobile feasibility spike on 2026-07-29:

• Trigger: agent-relay workspace active --json from a directory whose active workspace had been minted through the messaging plane.
• Request shape surfaced by the CLI: GET https://cast.agentrelay.com/api/v1/workspaces/active?relay_workspace_key=[REDACTED]
• Observed response status: 404.
• The CLI error included the unredacted workspace key in the request URL. The value is intentionally omitted here; no response body was safely retained.
• In the same session, authenticated GET /api/v1/auth/whoami and GET /api/v1/workspaces both returned 200 and resolved the cloud account and its Default workspace, while the messaging-only workspace did not resolve through the cloud API.

This is consistent with the issue description: a workspace minted by node up can exist and work on the messaging plane without being bound to the signed-in cloud account. The request evidence is sanitized because the original query parameter is a live credential.