FR: register_container / setup_desktop should offer to install a @reboot boot hook for the relay

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

Type: feature request. Version: AD 1.9.213.

The gap AD already documents to itself

serve --supervise prints this on startup:

⚠ A full CONTAINER REBOOT still needs a boot hook (cron @reboot / your container's init) — the watchdog covers session teardown, not host reboot.

So AD knows the watchdog does not cover reboot, tells the operator once, at the moment they are least likely to act on it, and then nothing enforces it. Surveying four of my relay containers, none had a boot hook and none were even running --supervise — every one was a bare adom-desktop serve that would vanish on reboot and leave connected desktops in a reconnect loop with no relay to reconnect to.

Why the hook belongs at registration, and NOT in the Windows installer

Worth being precise about the placement, since the obvious phrasing ("have the installer do it") targets the wrong host:

The relay runs in the cloud container (Linux). The Windows installer cannot create a cron entry there.
register_container and setup_desktop run from inside the container, which is exactly where the hook must live.

So the right hook point is the container-side registration flow — the same one that already writes server entries and knows it has just made a container a participant in the relay topology.

Proposed behaviour

When register_container / setup_desktop sets a container up:

Detect whether the relay will survive a reboot (crontab @reboot, systemd user unit, or the image's init).
If not, offer to install one — @reboot <abs path>/adom-desktop serve --supervise — and say plainly what breaks without it.
Make it inspectable and idempotent: a --boot-hook / --no-boot-hook flag for non-interactive use, and re-running should not duplicate the entry.
Surface the state in a readiness/doctor field (relayBootHook: present|absent|unsupported) so an AI or an operator can verify rather than assume.

Why this is worth doing

The current failure is silent and delayed: everything works until a reboot, then a fleet of desktops sits in a reconnect loop against a relay that no longer exists, and the symptom appears far from the cause. For containers whose desktops control real hardware, "the relay came back by itself" should be the default, not a runbook step nobody was told about at the right time.

Related: #33 (default token / hardening), and the two relay-rotation bugs filed alongside this one.

1 Reply

John Lauer · 9d ago

Parking this one deliberately (owner decision, 2026-07-31): the cloud containers don't give us an init/systemd/cron authority we can reliably hook — that's a platform constraint of the container environment, not something register_container/setup_desktop can promise to solve. Where a real init exists (the HD-managed WSL2 workspace), the relay already runs as a baked-in systemd unit with Restart=always + starts at distro boot — so the pattern is implemented everywhere we have the authority to implement it.

For the containers, the current answer is the AI in the container: when the relay is found dead (health probe fails / desktops flapping), re-run serve --supervise — and note that as of 1.9.215 the token should be provided via the ADOM_AUTH_TOKEN env var (see #388). Your survey finding (four containers, none supervised) is fair evidence the guidance needs to be louder; the startup warning text will keep pointing at cron @reboot for images that do support it.

If the container platform ever grows a first-class boot hook, this issue is the right shape for wiring it into register_container — leaving it open-parked rather than closing.