setup_desktop/register_container emit a dead /proxy/8765/ relay URL for mapped-port service containers (silent never-connects)

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 · 17d ago

setup_desktop / register_container emit a /proxy/8765/ relay URL derived from the container slug. For any service container whose relay is exposed through a dedicated port mapping, that URL does not serve — so the connection silently never dials, and the tool explicitly tells you not to second-guess it.

Repro (2026-07-24, AD CLI in a Carbon service container):

In the factoryos service container, adom-desktop setup_desktop returned:

"server_url": "wss://drew2-factoryos-teo37o4xawq5.adom.cloud/proxy/8765/",
"server_config": { "name":"factoryos", "url":"wss://drew2-factoryos-teo37o4xawq5.adom.cloud/proxy/8765/", "auth_token":"adom-dev-token-2025", "auto_connect":true, "enabled":true },
"register_command": "adom-desktop register_container '{\"name\":\"factoryos\",\"url\":\"wss://drew2-factoryos-teo37o4xawq5.adom.cloud/proxy/8765/\"}'"

with the hint: "Do NOT hand-build the JSON — server_config IS it."

But that URL is dead, while the container's ACTUAL relay URL works. Verified by response signature (a live relay answers a bare GET or a WS handshake with 400; 404 means nothing is listening on that public path):

URL	GET	WS-upgrade	Relay live?
`drew2-adompnp-tusiw6g7b9ds.adom.cloud/proxy/8765/`	400	400	yes (proxy-path container)
`factory-backups-relay-uou3kkoexzka.adom.cloud/`	400	400	yes (mapped-port container)
`factoryos-relay-53qidsq9g8hq.adom.cloud/`	400	400	yes — the real one
`drew2-factoryos-teo37o4xawq5.adom.cloud/proxy/8765/`	404	404	no — what setup_desktop emitted

adom-desktop serve was running and healthy inside the container the whole time (127.0.0.1:8766/health → 200, process up since Jul 22). So this is purely a wrong-URL problem, not a dead relay.

Cause (best guess): the URL is composed from the container slug + /proxy/8765/ rather than resolved from the container's actual port mappings. Service containers that expose the relay via a dedicated mapped hostname (<name>-relay-<hash>.adom.cloud) are therefore mis-described. At least two of ours are in that shape: factoryos and factory-backups.

Why it bites hard: the failure is silent and misattributed. AD shows a configured connection that simply never connects; targets never lists the desktop; the natural next hypothesis is "the relay is down" or "the desktop isn't signed in", and the tool's own "don't hand-build the JSON" line actively discourages the one thing that fixes it. We lost time to this while wiring a service container to a machine PC, and only found it by diffing HTTP status codes against a known-good relay.

Asks:

Resolve the relay URL from the container's real port mappings (prefer the mapped hostname when one exists) instead of always composing <slug>/proxy/8765/.
Have setup_desktop verify the URL it is about to recommend (it can reach it from inside the container — a 404 vs 400 check is enough) and say so if it doesn't answer, rather than emitting it with a "this IS the JSON" assurance.
Soften that assurance to name the exception, e.g. "if your relay is exposed via a dedicated port mapping, use that hostname."
If register_container has the same slug-composition logic, fix it there too — that is the preferred, zero-paste path, so a wrong URL there lands silently in the user's cloud profile.

For reference, the entry that actually works for us:

{ "name": "factoryos", "url": "wss://factoryos-relay-53qidsq9g8hq.adom.cloud/", "auth_token": "adom-dev-token-2025", "auto_connect": true, "enabled": true }

2 Replies

John Lauer · 17d ago

Fixed in 1.9.179 (CLI-side; adom-wiki pkg update in the container to get it). Your cause guess was exactly right.

The bug: detect_server_url composed wss://<default_hostname>/proxy/8765/ and never looked at the container's actual port mappings. adom-cli carbon containers current returns a port_mappings map (host -> port) that names the dedicated relay host for service containers like factoryos; we simply never read it.

Ask 1 - resolve from real mappings. detect_server_url now checks port_mappings FIRST: a mapping whose port IS the relay port wins and yields wss://<that-host>/ (root, not /proxy/); otherwise it falls back to the proxy-path convention on default_hostname. Verified on a proxy-path container (gallia has no 8765 mapping, so it correctly still emits /proxy/8765/); your mapped-port containers will now get their <name>-relay-<hash>.adom.cloud host.

Ask 2 - verify before recommending. setup_desktop now probes the URL it is about to hand out, using exactly the signature you documented (a live relay answers a bare GET with 400; 404 means nothing is listening), and reports:

"relayUrlReachable": true,
"_relayUrlCheck": "VERIFIED: wss://... answers as a live relay."

and on a miss it says the URL does NOT answer, that the container probably exposes its relay on a dedicated mapped hostname, where to look (port_mappings), and explicitly: do not hand this config to the user until it answers, because a wrong URL fails silently. So the "don't hand-build the JSON" line no longer overrides a dead recommendation - the response now tells you when the recommendation itself is wrong.

Thanks for the 400-vs-404 table; that is what made the probe trivial to implement correctly.

John Lauer · 15d ago

Fixed in v1.9.179 (now on the fleet, 1.9.198). Both the wrong-URL and the silent-failure halves.

Auto-derivation from port_mappings. setup_desktop's URL detection now consults the container's port_mappings FIRST. If a host is mapped to the relay port (8765), it returns wss://<that-host>/ — the ROOT of the mapped host, not the /proxy/8765/ path. Only when there is NO such mapping does it fall back to wss://<slug>/proxy/8765/. So for your factoryos service container, setup_desktop now emits wss://factoryos-relay-53qidsq9g8hq.adom.cloud/ — exactly the real one from your table, not the dead proxy path. The container metadata comes from adom-cli carbon containers current (default_hostname, slug, port_mappings), one shell-out, reused by the URL and name helpers.

Probe + no more silent failure. Even so, setup_desktop now PROBES the URL before recommending it and returns relayUrlReachable + a _relayUrlCheck line. On a 404 it says explicitly: nothing is listening on that public path, the container probably exposes its relay on a dedicated mapped hostname, check port_mappings for a host mapped to 8765, and do NOT hand the config to the user until the URL answers. So the "AD shows a configured connection that never dials" trap is gone: the caller either gets the right mapped URL automatically, or a loud warning with the fix, never a dead URL presented as good.

Your response-signature table (400 = live relay answering, 404 = nothing listening) is exactly the discriminator the probe uses. Thanks for pinning it that precisely — the mapped-host-vs-proxy-path distinction is what the fix keys on.