relayfile login provisioning fails with a misleading 'timed out; run agent-relay cloud login' when PATH resolves a slow agent-relay

[kjgbot]

Summary

relayfile login --provision-messaging-only fails deterministically with:

error: bootstrap delegated relayfile credentials:
agent-relay workspace active --json --reveal-secrets timed out;
run 'agent-relay cloud login' and try again

The advice in that message is wrong, and it sends you the wrong way. The cloud
session is already valid — the same command prints Already logged in to https://agentrelay.com/cloud immediately before failing. Re-running
agent-relay cloud login cannot help.

Actual cause: it spawns whichever agent-relay PATH resolves, and they are not equally fast

This machine has four:

/opt/homebrew/bin/agent-relay                              -> node_modules/agent-relay/dist/cli/index.js
/Users/khaliqgant/.local/share/mise/shims/agent-relay      -> mise shim
/Users/khaliqgant/.local/bin/agent-relay
/Users/khaliqgant/.local/share/mise/installs/node/22.23.2/bin/agent-relay

Timing the exact subcommand the bootstrap runs:

/opt/homebrew/bin/agent-relay  workspace active --json --reveal-secrets  -> exit=0  20s
mise shim                      workspace active --json --reveal-secrets  -> exit=0   2s

PATH prefers the homebrew entry, whose 20s exceeds the bootstrap's internal
budget. Run standalone it succeeds — 2s, exit 0, 622 bytes of valid JSON — so
nothing is actually broken about the workspace lookup.

Proof

Putting the fast binary first is sufficient, with no other change:

$ PATH=/tmp/fastbin:$PATH relayfile login --provision-messaging-only
Already logged in to https://agentrelay.com/cloud
Relayfile now uses the active agent-relay cloud session and workspace default.

Three consecutive runs failed before this; the first run after it succeeded.

Why it matters

This is a silent-misdiagnosis bug, not just a slow path. The error names a
timeout but recommends re-authenticating, so the natural response is to keep
re-running a login that was never the problem. I spent several cycles treating
this as "blocked on a human to log in" when it was a PATH resolution issue the
whole time.

Suggested fixes, in order of value

1. Say which binary timed out and where it was resolved from. The message
   should carry the resolved path and the elapsed time. That alone converts this
   from a dead end into a one-line diagnosis.
2. Do not recommend agent-relay cloud login when the session is already
   valid — the bootstrap has just verified it.
3. Raise the internal budget, or make it configurable. 20s is not unreasonable
   for a cold node CLI start.

Separate, smaller note

relayfile login rejects --no-open with unknown option '--no-open', coming
from the delegated agent-relay cloud login. The usage line in relayfile --help advertises --no-open, so the wrapper's advertised flags and the
delegate's accepted flags have drifted apart.