Adom Bridge

Connecting Adom Bridge (ROG-Zephyrus, v2.1.184) to a full cloud container (ray/g3, default-vscode image) from Claude Code running in a terminal there, not in Hydrogen or VS Code. It took several dead ends and a manual workaround. Each problem below is one we hit on 2026-10-27; the order is the order we hit them.

1. setup_desktop says the relay URL is reachable, but the desktop can never connect through it

adom-bridge setup_desktop printed _relayUrlCheck: VERIFIED: wss://ray-g3-8njarqz7yruf.adom.cloud/proxy/8765/ answers as a live relay. On a full container that /proxy/ path sits behind the VS Code (code-server) login: a request without its cookie gets 302 to ./../../login. Adom Bridge on the laptop got nowhere, and nothing on either side said why. Pasting that server JSON into Connections showed a green check and Add Server, then never connected.

Expected: the check makes the request the desktop will make (no cookie) and fails on a login redirect. On a full container, the setup flow should say "this URL needs a port mapping" and offer to create one.

2. register_container is read only when Adom Bridge starts

register_container writes the entry into the Adom profile, and its own hint says Adom Bridge "polls carbon-prefs at boot only". A user who is already signed in sees nothing until they quit and relaunch. It should poll, or be pushed, while running.

3. The working path: a port mapping, which the docs don't mention

What finally worked: adom-cli carbon containers port-add <slug> --port 8765 --prefix g3-relay, with the relay restarted with --bind 0.0.0.0. The default 127.0.0.1 bind makes the mapping answer 502. Nothing in setup_desktop, register_container or the skills points at this. It should be the documented path for full containers, ideally one command.

4. The default dev token is the default, even when the relay ends up public

The relay ran on adom-dev-token-2025, which is printed in the docs. Once a port mapping exists, anyone with the URL can join the relay and drive every connected desktop. The relay log does warn about this, but setup_desktop's server JSON carries auth_token: "" and nothing makes a real token. Expected: setup makes a random per-container token, stores it owner-only, starts the relay with it, and puts it in the register_container entry so the user never types it. That is what we did by hand.

5. relay_boot_hook forgets the token and the bind

relay_boot_hook {"action":"install"} wrote @reboot ... adom-bridge serve --supervise. After a reboot the relay would come back on the default token and the loopback bind: the public mapping would then give either a 502 or an open relay. The hook should record the token source and bind the relay is running with. We edited the crontab by hand.

6. A relay on a custom token needs ADOM_AUTH_TOKEN on every CLI call, and every desktop call needs a caller identity

Expected, but undocumented in setup: after the token change every adom-bridge call needs ADOM_AUTH_TOKEN, and ping --target is refused without ADOM_AI_THREAD (targets works without it). A terminal session can set these itself; setup_desktop could print the three env lines to export.

Summary of the flow that worked

1. A random token, stored at ~/.config/adom-bridge/relay_token (mode 600).
2. ADOM_AUTH_TOKEN=... adom-bridge serve --supervise --bind 0.0.0.0
3. A port mapping for 8765.
4. register_container {url: wss://<mapping>/, auth_token, force: true}.
5. The user quits and relaunches Adom Bridge.
6. The @reboot line carries the token and the bind.

Each step is mechanical, so all of it could be one verb.