Surface token-mismatch auth failures clearly (client + relay), not a silent clean close

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues40 Breadcrumbs Pull Requests Activity

Open general

Drew Owens · 3d ago

The ask

When a desktop connection fails because its registered relay token does not match the relay's token, surface that clearly on both sides. Today it looks like a mysterious flap, and diagnosing it means reading the relay log.

What it looks like now

After a relay token rotation, a container's registered auth_token can go stale (still adom-dev-token-2025) while the relay runs a rotated token. Every reconnect then loops like this, forever:

Relay log: WS connected → type=auth → Auth FAILED → sent Close frame → WS disconnected (every 30s).
Client (AD): Connecting… → Connected, authenticating… → Authenticated → Connection closed cleanly after ~200ms → Reconnecting in 30s.
Manual Connect: Connect failed: Server 'X' is already connected or connecting.

Nothing on the client says auth failed or token mismatch. "Closed cleanly" and "Authenticated" actively mislead: it reads like a network blip, not a rejected credential. It took reading relay.log on the container to find the Auth FAILED line.

Requested changes

Client-side state. When the relay closes a connection for auth reasons, show a distinct, honest state, for example: "Authentication failed: the server rejected this connection's token. Update this server's token." Do not report the connection as "Authenticated" or "closed cleanly" when the server rejected it.
Relay-side close reason. Have the relay send a close code + reason on auth failure (e.g. a WS close code plus auth_failed: token_mismatch) so the client can render it. The relay already logs Auth FAILED; propagate that to the peer instead of a bare clean close.
A pointer to the fix. Since the registration's auth_token is not auto-updated on rotation, the message should hint at the remedy (re-register / update this server's token).
Disambiguate the manual-Connect error. already connected or connecting (client's own retry state) should read differently from a real server-side auth rejection, so a user clicking Connect during the loop is not told the wrong thing.

Why it matters

Token rotation is a normal operation and the registration token does not follow it automatically, so this exact failure mode will recur across containers. A clear message turns a log-diving investigation into a one-glance fix.

Filed after diagnosing an AdomPNP relay that looped for days on a stale token; the only signal was Auth FAILED buried in a 380 MB relay.log.

Adom Bridge