GET http://127.0.0.1:<control-port>/updater/status

POST http://127.0.0.1:<control-port>/updater/install

---
name: hd-self-update
description: "How the AI keeps the Hydrogen Desktop APP itself (the Windows/macOS frontend, not the workspace) up to date — AI-first, consent-based. Use when asked \"is there an HD update\", \"update Hydrogen Desktop\", \"is my HD current\", \"what version of HD am I on\", \"update the app\", \"new HD version\". Trigger words: HD update, update hydrogen desktop, app update, is HD current, HD version, new version of HD, relaunch to update, self-update."
---

# HD Self-Update — the app updates itself (a banner + an AI path)

This is how the **Hydrogen Desktop app itself** (the Windows/macOS shell around your editor)
stays current. It is NOT how the in-distro tooling/skills update (those converge registry-native
via `adom-wiki pkg update` + the `adom/hook` prompt hook). There are **two ways** a new HD version
gets applied, and they share one backend:

1. **The Restart-to-update banner (what the user sees).** When the updater supervisor
   (`updater.rs`) has silently downloaded + SHA-verified a newer version in the background, HD
   shows a top-of-app bar: **"Restart to update (vX → vY)"** (`UpdateBanner.svelte`). One click
   calls `updater_install` and relaunches onto the new version. If the user ignores it, the staged
   update auto-applies on the next launch anyway.
2. **The AI-first path (you).** You can also proactively notice a new version, tell the user both
   numbers, and on their OK apply it — same backend, no waiting for the banner.

## When to check
Check at the **start of a session** and whenever the user asks about updates. Don't poll
constantly.

## How to check (know both version numbers)
```
GET http://127.0.0.1:<control-port>/updater/status
```
Returns `{ current_version, latest_version, update_available, staged, ... }`:
- `update_available: true` → a newer HD exists.
- `staged: true` → it's already downloaded + SHA-verified in the background, so applying is an
  **instant relaunch** (no wait).
(`current_version` is also derivable from `/buildinfo`; `latest_version` comes from the wiki
`version.json`. `/updater/status` gives you both in one call.)

## What to do
If `update_available`, **tell the user both versions and ASK** — e.g.:
> "Hydrogen Desktop **vX → vY** is available (already downloaded). Want me to update and relaunch?
> Takes a few seconds; this workspace and our chat reconnect right after."

On **explicit consent**:
```
POST http://127.0.0.1:<control-port>/updater/install
```
HD applies the staged update (instant if `staged`, else downloads first) and relaunches onto the
new version. **The Linux workspace + code-server keep running**, so your session reconnects in a
few seconds — you can pick the conversation right back up.

## Rules
- **Consent-first.** Never relaunch HD without the user's OK (it restarts their app). Pick a
  natural break — not mid-task.
- **State both versions** (current → latest) so the user knows what's changing.
- This updates the **app shell only**. Editor extensions/code-server use their own reload banner;
  in-workspace tooling/skills converge registry-native (`adom-wiki pkg update` via `adom/hook`).
  Don't confuse the three.

## Resolving the control port
Read it from `VSCODE_PROXY_URI` / the HD `[ports]` log line (default control API `47084`), or
reach it through the relay/proxy like other HD control endpoints.