HarnessLink updates itself (ADR-71): every hour the background service checks the latest release, stages it beside the running install (~/.hnl-src.next: download, bun install --production, hnl --version and hnl --smoke-test), and swaps it in and restarts only when the machine is idle: no harness session on the MCP hub and no HarnessLink hook for 15 minutes, re-checked every 10 minutes, and installed anyway after 24 hours. One attempt per release; a failure keeps the current version, backs off 6 hours and shows in hnl, hnl status and hnl daemon status. Turn it off with update.auto: false; hnl update stays the manual path and shares the update lock. Git checkouts and runs from source never update themselves.
The Devices page and Settings › Devices show each machine's hnl version and whether it is up to date, updating soon, or behind by N releases (with hnl update as the manual fallback); "Version unknown" for a machine on a CLI from before versions were recorded. The owner console's user and organisation device lists show the version too. The server records it from the User-Agent every CLI call already sends (control migration 0050: devices.client_version, client_version_at; written at most hourly unless it changes), and GET /v1/devices, GET /v1/org/devices and the owner device lists return client_version and client_version_at.

Flag notifications