fix(setup): stop --skip-mount prompting for a mount dir; name the unbound-workspace failure

[miyaontherelay]

Two verified production failures in relayfile setup 0.10.53.

1. --skip-mount still prompted and blocked on stdin

runSetupWithOptions prompted Local mount directory [./relayfile-mount]: whenever --local-dir was omitted, regardless of --skip-mount. --skip-mount is the headless contract — setup finishes without starting the mount process — so a run with --no-open had no terminal to answer and the read blocked forever.

Under --skip-mount, setup now takes the value the prompt's default would have produced instead of asking. The directory is still used (the mirror layout is created there, and the printed relayfile mount <id> <dir> hint names it), so nothing else about the run changes. Interactive setup is untouched.

2. setup cannot create a usable workspace — the root cause is cloud-side

resolveCloudWorkspaceForRelayfile collapsed two different Cloud states into one message:

Cloud did not return cloudWorkspaceId and relayfileWorkspaceId; workspace provisioning did not complete

For a CLI-created workspace that message is wrong. Provisioning did complete. What actually comes back is relayfileWorkspaceId: "rw_…" and cloudWorkspaceId: null, because nothing binds a CLI-created relay workspace to a Cloud workspace:

• POST /api/v1/workspaces without createAppWorkspace: true calls registry.create(...), which writes only the relay-workspace row. It never sets workspaces.relayWorkspaceId on the app workspace.
• GET /api/v1/workspaces/{id}/resolve reads that binding. On the rw_* branch it returns cloudWorkspaceId: binding.appWorkspaceId, which is null for an unbound workspace. Only the app-workspace-UUID branch provisions (resolveOrProvisionRelayWorkspace).
• The CLI cannot send createAppWorkspace: true: that branch requires requireSessionAuth, and the CLI authenticates with a cli:auth bearer (source: "token"), so it would 403.

This PR splits the two checks so the error names the real state instead of blaming provisioning.

Why this PR does not just tolerate a null cloudWorkspaceId

Tolerating it would not produce a usable workspace — it would only move the failure one step later, to a message that cannot explain itself. The next call setup makes is POST /api/v1/workspaces/{rw_*}/relayfile/delegated-token, whose hasWorkspaceAccess gate is:

if(rawWorkspaceId===auth.workspaceId)returntrue;// rw_* != app UUID
...
constbinding=awaitresolveAppWorkspaceByRelayWorkspaceId(rawWorkspaceId);if(!binding.appWorkspaceId)returnfalse;// unbound -> false

which returns 404 workspace_not_found. So the CLI fails fast at the step that can name the cause.

The fix that makes relayfile setup work is cloud-side: POST /api/v1/workspaces (the cli:auth, non-createAppWorkspace path) must bind the new relay workspace to the caller's app workspace, or resolve's rw_* branch must provision that binding the way the UUID branch already does. That change belongs in AgentWorkforce/cloud and is out of scope here.

Worth noting for whoever picks that up: the cloud tests that cover this path all mock resolveAppWorkspaceByRelayWorkspaceId to return a non-null appWorkspaceId (workspaces/create-resolve.integration.test.ts, [workspaceId]/resolve/route.test.ts incl. "resolves a direct rw_ workspace id without app provisioning"). No test exercises the unbound case, which is why this shipped.

Tests

New file cmd/relayfile-cli/setup_headless_test.go:

• TestSetupSkipMountDoesNotPromptForLocalMountDirectory — headless --skip-mount --no-open run with a stdin reader that errors on any read. Asserts setup succeeds, never reads stdin, never prints the prompt, prepares ./relayfile-mount, and issues exactly create → resolve → delegated-token.
• TestSetupNamesUnboundCloudWorkspaceOnResolve — replays the production resolve payload (cloudWorkspaceId: null, relayfileWorkspaceId: "rw_1234abcd"). Asserts the error names the unbound binding and that setup stops before the delegated-token call.
• TestResolveCloudWorkspaceForRelayfileSeparatesUnprovisionedFromUnbound — the two states now produce distinct errors.

All three were confirmed to fail against the unfixed code (the --skip-mount case reproduces Local mount directory [./relayfile-mount]: and the blocking read).

go build ./..., go vet ./cmd/relayfile-cli/, gofmt -l, go test ./... (full repo, -count=1 on cmd/relayfile-cli, 126s) and scripts/check-contract-surface.sh all pass. No HTTP surface changed, so the OpenAPI spec is untouched.

Not run: no live run against production Cloud. The cloud-side mechanism above is established by reading AgentWorkforce/cloud@origin/main, not by executing it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kk8xnrAeA3QfS4A9n6dAd3

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 601421fa-1ce2-4a57-b108-494f7d7d6e52

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Relayfile Eval Review

Run: .relayfile/evals/runs/2026-09-05T11-07-13-241Z-HEAD-provider
Mode: provider
Git SHA: 758b0c9

Passed: 4 | Needs human: 0 | Reviewable: 0 | Missing output: 0 | Failed: 0 | Skipped: 0

Human Review Cases

No reviewable human-review cases captured Relayfile output.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="cmd/relayfile-cli/setup_headless_test.go">
<violation number="1" location="cmd/relayfile-cli/setup_headless_test.go:46">
P3: In the cleanup registered by chdirForTest, t.Fatalf calls FailNow (runtime.Goexit), which aborts the test goroutine from inside a cleanup. That stops the remaining cleanup functions (LIFO) and marks the test failed in a way that the testing framework does not reliably attribute to a normal cleanup failure. Use t.Errorf in the cleanup so the restore failure is reported without aborting the cleanup chain.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: In the cleanup registered by chdirForTest, t.Fatalf calls FailNow (runtime.Goexit), which aborts the test goroutine from inside a cleanup. That stops the remaining cleanup functions (LIFO) and marks the test failed in a way that the testing framework does not reliably attribute to a normal cleanup failure. Use t.Errorf in the cleanup so the restore failure is reported without aborting the cleanup chain.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At cmd/relayfile-cli/setup_headless_test.go, line 46:
<comment>In the cleanup registered by chdirForTest, t.Fatalf calls FailNow (runtime.Goexit), which aborts the test goroutine from inside a cleanup. That stops the remaining cleanup functions (LIFO) and marks the test failed in a way that the testing framework does not reliably attribute to a normal cleanup failure. Use t.Errorf in the cleanup so the restore failure is reported without aborting the cleanup chain.</comment>
<file context>
@@ -28,11 +28,31 @@ func (r *refusingStdin) Read([]byte) (int, error) {
+	}
+	t.Cleanup(func() {
+ if err := os.Chdir(previous); err != nil {
+ t.Fatalf("restore working directory: %v", err)
+ }
+	})
</file context>