hook
Public Made by Adomby adom
Registry-native cross-agent auto-update hook, plus claude-rc, the keeper for Claude Remote Control. Keeps adom/core apps and skills current from wiki.adom.inc on every Claude Code and Codex prompt, and keeps `claude rc` alive so users can open AI threads on their container from the Claude mobile app or claude.ai/code.
Service containers never auto-update: the hook only fires on UserPromptSubmit, and every failure is silent
The auto-update hook only fires on UserPromptSubmit. A container that never submits an interactive prompt never checks for updates, and never reports that it is not checking.
Evidence
Live CLI telemetry (/api/admin/clients?name=adom-wiki-cli&days=1) after 1.0.78 shipped:
1.0.78 296 req 9 users <- released ~16h earlier
1.0.77 246 req 9 users <- rolling forward normally
1.0.67 84 req 1 user
1.0.1 47 req 1 user <- first seen 2026-07-22, still on 1.0.1
1.0.59 36 req 1 user
1.0.43 30 req 3 users
1.0.65 16 req 1 user
Auto-update works. Nine distinct clients reached 1.0.78 within sixteen hours. That half is fine.
The stragglers share a shape: one user, steady request volume, weeks behind. 1.0.67 made 84 requests in a day while being ten releases old. That is not a person who forgot to update, that is a service container doing scheduled work. It has no interactive agent, so UserPromptSubmit never fires, so check-updates.sh never runs, so it is pinned to whatever version it was provisioned with, indefinitely.
Why it is invisible
check-updates.sh has three exits that produce no signal anywhere:
command -v adompkg >/dev/null 2>&1 || exit 0 # no adompkg: silent forever
if timeout 12 adompkg outdated --quiet >/dev/null 2>&1; then exit 0; fi # probe says "current"
( adompkg update >/dev/null 2>&1; adompkg install adom/core >/dev/null 2>&1 ) & # failures discarded
Every path is >/dev/null 2>&1. A container can be frozen for nine days and nothing anywhere says so. This is the same shape as the bootstrap outage, where a dangling dep on a deleted package froze every container for four days because the hook swallowed the 404. That was fixed by fixing the dep, not by making the silence audible, so the next cause will take just as long to find.
Also worth knowing
The whole update path runs through adompkg, which self-reports as retired:
$ adompkg --version
DEPRECATED: adompkg is retired and no longer maintained. Use the adom-wiki CLI.
So the mechanism that keeps adom-wiki current depends entirely on a tool we have deprecated. It works today. When it stops, every container freezes at once, silently, with no natural recovery, and the first symptom will be something unrelated failing weeks later.
Ask
Three things, in order of value:
- A non-interactive update path. Cron, systemd timer, or a check on service start. Anything that does not require a human to type. This is the actual gap.
- Make failure audible. The hook should record its last outcome somewhere readable (a stamp file with the exit reason is enough), and ideally report the client version on check-in so
/api/admin/clientsshows stale and not checking rather than just stale. Silence currently reads identically to success. - Move the hook off
adompkgontoadom-wiki. Otherwise the retired tool is a single point of failure for the entire fleet's ability to update itself.
Not urgent, and worth saying why
Nothing is broken right now. Interactive containers update within hours. The stuck ones are a handful of services, and the flag that surfaced this (--preset public) is not being adopted yet precisely because the drain gate correctly says safe_to_drop: false. The gate is doing its job. This issue is about the fact that we found the gap by accident while looking at something else.