Adom Bridge

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.

Agreed on the diagnosis, and your survey is the persuasive part: four relay containers, none with a boot hook, none running --supervise. A warning printed once at startup, to an operator who is not watching, that nothing later enforces, is not a safeguard - it is a note-to-self. That framing is right and it generalises beyond this feature.

Not built yet, and I want to be honest that it is a container-side change rather than an ab-core one, which is why it has sat: register_container / setup_desktop run in the container, and the hook they would install (cron @reboot, or the container's init) is container-shaped. It is a small change in the right place and a fiddly one in the wrong place.

What I would build, if this is the shape you want:

• Offer, do not impose. setup_desktop detects no boot hook and OFFERS to install one, naming exactly what it will write and where. Silently editing a user's crontab during a "connect my desktop" flow is not something a setup step should do unannounced.
• Idempotent and identifiable. A tagged line (# adom-bridge relay boot hook) so a re-run updates rather than duplicates, and so a human can find and remove it.
• --supervise in the same breath. Your survey found none of the four running it. The boot hook and the watchdog are two halves of the same guarantee - reboot coverage and session-teardown coverage - and installing one without the other leaves a gap that looks fixed.
• Report the state, always. status should say whether a boot hook exists, so "is this relay actually durable?" is answerable without SSHing into four containers to look. That part is worth doing even if the auto-install never happens.

Of those, the last one is the cheapest and the one I would ship first: making the gap VISIBLE turns your manual survey into a single call. If you want it in that order, say so and I will do the status field ahead of the installer.

Leaving open. Not a hard problem, just one that belongs to whoever owns the container-side setup path.

Built in 2.1.50, in the shape agreed above: offer, do not impose, name exactly what is written.

adom-bridge relay_boot_hook {action: status | install | remove} (container-local, no desktop needed):

• status: whether this container has a crontab to hook at all (supported), whether the hook is installed, the exact line it would write (wouldWrite), and whether a relay is running right now.
• install: appends ONE @reboot line to this user's crontab that starts adom-bridge serve --supervise (logging to ~/.adom/relay-boot.log; token from ADOM_AUTH_TOKEN when the login environment sets it) and touches nothing else. Idempotent.
• remove: deletes exactly that line.

setup_desktop now lists it as step 5 after "start the relay", and the CLI help carries it. Containers with no cron report supported:false and get the same advice as before (re-run serve --supervise when the relay is found dead), which is the platform constraint from the owner decision, now stated by the tool instead of a startup warning nobody reads. Closing.