Fresh-user setup cannot complete: login and workspace commands use different credential stores

[khaliqgant]

Summary

A brand-new user cannot complete npx relayfile@latest setup. Sign-in succeeds, then setup fails with:

error: mint delegated relayfile credentials: http 404 workspace_not_found: Workspace not found

The underlying cause appears to be that the device-auth login and the workspace subcommands do not read the same credential store, so immediately after a successful sign-in the CLI behaves as though nobody is logged in.

Verified against published 0.10.47 on macOS (arm64), Node 22.22.2, in a fully isolated environment: fresh HOME, fresh npm cache, fresh npm prefix, fresh cwd, env -i. Not a stale-config artifact.

Reproduction

npx relayfile@latest setup --no-open

Complete the device authorization in a browser, then answer the three prompts.

Observed, with all three prompts genuinely answered over a real PTY (driven with expect, values echoed back correctly):

Logged in to https://agentrelay.com/cloud
Signed in as <user> (<Workspace Name>)
Workspace name [relayfile-20260823-204739]: relayfile-onboard-probe-0823
Integration (...) [github]: none
Local mount directory [./relayfile-mount]:
error: mint delegated relayfile credentials: http 404 workspace_not_found: Workspace not found

Evidence that this is a credential-store split, not a bad workspace name

Immediately after that successful sign-in, in the same isolated HOME:

$ relayfile workspace list --names-only
(empty)

$ relayfile workspace current
error: no active workspace; pass WORKSPACE, set RELAYFILE_WORKSPACE, or run 'agent-relay workspace switch NAME'

$ relayfile workspace create relayfile-onboard-probe-0823
error: credentials not found at $HOME/.relayfile/credentials.json;
       run relayfile login --api-key for self-hosted credentials or pass --token

But the login did persist credentials — just somewhere else:

$HOME/.agentworkforce/relay/cloud-auth.json       -rw-------
$HOME/.agentworkforce/relay/cloud-identity.json   -rw-------
$HOME/.relayfile/catalog-cache.json               -rw-r--r--

So workspace create looks for ~/.relayfile/credentials.json, while the device-auth flow writes ~/.agentworkforce/relay/cloud-auth.json. ~/.relayfile/ exists and contains only a catalog cache — no credentials.

That single split explains every symptom coherently: workspace list returns empty for a signed-in user, workspace current reports no active workspace, workspace create reports no credentials, and setup therefore tries to mint delegated credentials for a workspace it was never able to create — producing the 404.

Why every fresh user hits this

The workspace-name prompt defaults to a newly generated name (relayfile-<timestamp>). Whatever the intended semantics, that default cannot refer to an existing workspace, so accepting the default is guaranteed to 404. There is no path through the prompts that succeeds:

• accept the default -> new name -> 404
• type a new name -> 404
• create the workspace first -> workspace create says credentials not found

One observation I am explicitly not drawing a conclusion from

The sign-in banner prints Signed in as <user> (<Workspace Name>), naming a real workspace the account owns — while workspace list in the same session is empty. Either the banner reads identity from the cloud-auth store while list reads the other one (consistent with the split above), or list is scoped to something different. Worth confirming rather than assuming.

Also note the error text mentions --api-key and "self-hosted credentials", so it is possible workspace create is a self-hosted-only path and the hosted flow is meant to provision differently. If so, the defect is that the hosted setup path has no working provisioning step at all, rather than that it calls the wrong one. Either way the fresh-user outcome is the same.

Credential hygiene — a positive finding, recorded deliberately

cloud-auth.json and cloud-identity.json are written 0600 inside 0700 directories. That is correct and worth stating, because a related defect was filed today in a different component where a generated script was written 0644 with a token inline (AgentWorkforce/sandbox#30). The local CLI path does this correctly.

Impact

This is the first-run path for every new user. It is not reachable by any automated test that stops short of a real browser sign-in, which is why it survived a full day of verification: an agent could prove the tarball contents, the sign-in URL, --no-open, timeout propagation and cancellation behaviour, but the failure only appears after a human completes the device authorization.

Suggested fix direction

1. Make the login and workspace subcommands share one credential store, or have the workspace commands fall back to the cloud-auth store.
2. Have setup explicitly create the workspace it prompted for before minting delegated credentials, and fail with a message naming the missing step rather than a raw HTTP 404.
3. If the prompt is meant to select rather than create, default it to an existing workspace and list the available ones.

Environment

• relayfile 0.10.47 (published; npx relayfile@latest)
• macOS arm64, Node 22.22.2, npm 10.9.7
• Isolated HOME, npm cache, npm prefix and cwd via env -i; real ~/.relayfile untouched
• Prompts driven over a real PTY via expect; answers confirmed echoed

[khaliqgant]

Corollary from the same root cause: relayfile logout reports success without ending the session

While cleaning up the probe environment I ran relayfile logout in the same isolated HOME, moments after a successful device sign-in. It printed:

Relayfile is already logged out.
Agent Relay cloud session left intact; run `agent-relay cloud logout` to fully sign out.

"Already logged out" — immediately after logging in, in the same HOME, with cloud-auth.json present on disk at the time.

This is the same credential-store split viewed from the other end. relayfile logout checks ~/.relayfile/credentials.json, finds nothing, and concludes there is no session. The session that actually exists lives in ~/.agentworkforce/relay/cloud-auth.json and is untouched.

Why this half is worse than the setup failure

The setup failure is loud: you get a 404 and you know you are stuck. This one fails in the affirmative. A user who signs in on a shared or temporary machine and then runs relayfile logout gets a success-shaped message and reasonably believes they have signed out. They have not. The credential is still on disk and the cloud session is still live.

To the CLI's credit the second line does say the cloud session is left intact and names the command that would end it, so the information is present. But the first line is the one that reads as the outcome, and it is wrong. A logout that cannot see the session it is being asked to end should say it could not find and verify one, not assert that none exists.

Suggested handling

Whatever fixes the store split should fix both directions at once:

• logout should end the session the login path created, not a different store's.
• Until then, the message should not lead with "already logged out" when a cloud session is present. Inverting the two lines would be a meaningful improvement on its own.

Disclosure about this probe

The credential minted during this investigation was removed from disk, but because relayfile logout did not actually revoke it, the server-side session may still be live. It was created deliberately for this test in an isolated HOME on the account owner's own machine, and the owner has been told directly so they can revoke it with agent-relay cloud logout if they choose. Recording it here so the trail is complete rather than tidy.

[miyaontherelay]

Step 0 environment report (implementation lane):

• pwd: /Users/khaliqgant/.agentworkforce/relay/finn-mini-node
• hostname: Finn-Mac-Mini
• disk: /dev/disk3s5 228Gi size, 164Gi used, 32Gi available, 84% capacity
• Go: go version go1.26.1 darwin/arm64
• Node: v25.8.1
• npm: the executable is /opt/homebrew/bin/npm; npm --version hung without output and was interrupted after 30s. Its installed package metadata reports 11.11.0.
• Git: git version 2.50.1 (Apple Git-155)
• gh auth status account/scopes verbatim:
  • ✓ Logged in to github.com account miyaontherelay (/Users/khaliqgant/.config/gh/hosts.yml)
  • Active account: true
  • Git operations protocol: ssh
  • Token scopes: 'admin:public_key', 'gist', 'read:org', 'repo'
• Fresh clone command: git clone git@github.com:AgentWorkforce/relayfile.git relayfile
• Fresh clone result: success, clean main...origin/main, at /tmp/relayfile-440.cXT5o4/relayfile.
• GitHub API quota: core 5000/5000 remaining; GraphQL 4997/5000 remaining; search 30/30 remaining.
• No separate model/credit quota is exposed in this environment.

All mandatory PR prerequisites (Go, Git, GitHub auth with repo scope, fresh clone) are available. Proceeding from a branch based on origin/main; no code has been changed yet.

[miyaontherelay]

Red-before-green and credential-store inventory from the implementation lane:

The two modes are confirmed as intentional.

• Hosted: ~/.agentworkforce/relay/cloud-auth.json is written by the bundled setup/device-auth flow and agent-relay cloud login; Relayfile reads it through ensureAgentRelayCloudSession, and the Go refresh path writes rotated tokens back to that same file under the shared lock. The setup/bootstrap/delegated-token paths consume this hosted session. packages/agents/src/connect.ts is another reader.
• Self-hosted/API-key: ~/.relayfile/credentials.json is written only by relayfile login --api-key / explicit token login (saveCredentials). It is read by the legacy workspace/admin, mount, seed, ops, and writeback command paths through loadCredentials. It is not a hosted-session cache.
• Two existing hosted paths delete credentials.json (runLogin after cloud bootstrap and prepareWorkspaceCommandClient after delegated bootstrap). That is destructive to a legitimate coexisting self-hosted configuration and will be removed. The planned precedence is: explicit flag, environment token, canonical hosted session, self-hosted file. Neither store will be migrated or rewritten into the other.
• The fresh setup 404 is also an ID/provisioning boundary: POST /api/v1/workspaces returns a Cloud app workspace ID, while the delegated-token route requires the resolved relayfileWorkspaceId. Main currently mints directly against the create response ID without calling /resolve.
• Current logout deletes Relayfile-owned files but deliberately leaves the canonical hosted session intact, which reproduces the issue comment exactly.

New tests were added first and run against unmodified production code. Red evidence:

TestWorkspaceListUsesCanonicalCloudSessionForFreshUser: output = ""
TestFreshUserSetupCreatesAndResolvesWorkspaceBeforeMinting:
  requests = [POST /api/v1/workspaces POST /api/v1/workspaces/<cloud-id>/relayfile/delegated-token]
  error = mint delegated relayfile credentials: http 404 workspace_not_found: Workspace not found
TestSetupNamesMissingWorkspaceProvisioningStep:
  raw 404 does not name the create/provision step
TestLogoutAfterCloudLoginRevokesAndClearsCanonicalSession:
  no refresh token was revoked and the canonical session remained
TestWorkspaceCreatePrefersCanonicalCloudSessionWithoutRewritingSelfHostedCredentials:
  got 0 Cloud requests, want create, resolve, and mint

The self-hosted-only regression guard passes on main and byte-compares credentials.json before/after workspace create to ensure the legacy file remains usable and unchanged.

[miyaontherelay]

Implementation PR opened: #441

The PR fixes the full first-run chain and logout corollary:

• hosted setup now creates the prompted workspace, resolves the Cloud app ID to relayfileWorkspaceId, then mints delegated credentials against that resolved ID;
• workspace create/list/current use the canonical hosted session before the self-hosted fallback;
• hosted commands no longer delete or rewrite an existing ~/.relayfile/credentials.json;
• workspace_not_found names the missing create/resolve/provision step;
• logout revokes the canonical refresh token and verifies canonical auth/identity state was cleared; failed revocation returns an error and retains the credential for retry.

Verification before push:

• go test ./cmd/relayfile-cli -count=1 — pass
• go test ./... -count=1 — pass
• go vet ./... — pass
• git diff --check — pass

Branch was created from origin/main, committed as bffdaf6, and pushed with upstream tracking. No merge, release, publish, or tag action was taken.

[miyaontherelay]

Final implementation handoff: PR #441 is ready for maintainer review.

• PR: fix(cli): make fresh setup and logout use canonical cloud auth #441
• Final head: 6db46adf01c2e9d89cd13e88536f3aa9eb002860
• Branch: fix/440-credential-store-setup (clean and pushed with upstream tracking)

What changed:

• Hosted workspace commands now use the canonical ~/.agentworkforce/relay/cloud-auth.json session while preserving ~/.relayfile/credentials.json as the non-destructive self-hosted/API-key fallback. Precedence is explicit flag, environment token, canonical cloud session, then self-hosted credentials.
• Fresh setup now creates the prompted workspace, resolves the Cloud workspace ID to its Relayfile workspace ID, and only then mints delegated credentials. Missing provisioning now produces an actionable create/resolve/provision error instead of a raw 404.
• Existing self-hosted users keep their credentials file byte-for-byte; hosted login/bootstrap no longer deletes it.
• Logout revokes the refresh token through the Cloud API under the auth lock, deletes hosted auth only after a verified 2xx response, reads state back to verify removal, and retains the session on revoke failure rather than claiming success. Self-hosted-only logout reports its actual source accurately.
• Cloud workspace selection avoids a same-name self-hosted workspace collision.

Red-before-green coverage was captured earlier in this issue. Final local verification:

• go test ./cmd/relayfile-cli -count=1 — pass
• go test ./... -count=1 — pass
• go vet ./... — pass
• git diff --check — pass

Final-head CI, checked per workflow with gh run list:

• CI run 32667491195 — success
• Relayfile Evals run 32667491233 — success; 4 passed, 0 needs-human-review, 0 reviewable, 0 missing output, 0 failed, 0 skipped
• Contract run 32667491191 attempt 2 — success. Attempt 1 had only an unrelated flaky internal/mountsync TempDir cleanup (directory not empty); the failed workflow was rerun and every Contract step passed on attempt 2.

Review-body audit:

• CodeRabbit's requested review was rate-limited; its full response was read and it did not produce a review.
• GitHub currently reports 0 reviews, 0 review threads (therefore 0 unresolved threads), and 0 inline review comments on PR fix(cli): make fresh setup and logout use canonical cloud auth #441.
• No Devin or other bot review body/thread is present.

No merge, publish, release, or tag was performed.