Hermes unattended update guides

Primary-source reading map. Checked October 14, 2026. This is a guide index, not an installed or tested automation system.

Start with the official updater and supervisor guides, not a replacement updater. Native documentation covers chat updates, update receipts, deferred restart obligations and OS scheduling. Combining these into safe unattended maintenance still requires host-specific validation.

1. Official update lifecycle

Updating & Uninstalling [1]

Read “Updating from Messaging Platforms” for the built-in chat update path.
Read “Automated updates from inside the gateway: --no-gateway-restart” for the self-restart lifetime problem and the documented split update/restart approach.
Read “Fleet preview” and “Update receipts and the fleet version check” for observing services before an update and checking actual restart outcomes afterward.
Read “Local commits on the target branch” and “Checkout parked on a feature branch” before replacing any updater that preserves local patches.

Patch-preservation warning: native stable selection checks out an exact release. The documented custom-branch updates.parked_branch_strategy: update_in_place path merges the source branch; it is not proof of a stable-release merge preserving carried patches. The guide also warns that divergent commits on the update target main are backed up before reset. Do not blindly substitute native defaults for a carried stable-merge policy. [1]

2. Chat control and Slack approvals

Slash Commands Reference [2] documents /update, /restart, /approve and /deny. The restart command drains active work and returns confirmation to the requester's chat/thread.

Slack guide [3] explains approval buttons. Text fallbacks in threads use !approve and !deny. These are existing request responses, not universal permission overrides.

3. Native updater completion ownership

Source update completion ownership [5] is the engineering guide: the parent owns admission and the update lock; the selected new runtime owns completion; a correlated terminal response is required. Read “Parent lifecycle and failures” and “Crash-cell matrix” before creating a worker.

Do not accept exit 0 as proof of full activation. The documentation explicitly allows post-commit follow-up debt, including gateway restart or dependencies, while the overall update exits 0. Read the receipt and live fleet identity. [5]

4. macOS: OS-owned maintenance, not a bot child

Apple: Creating Launch Daemons and Agents [6] explains ProgramArguments, KeepAlive, on-demand jobs and process ownership. Apple explicitly says a launchd-managed process must not daemonize itself.

Apple: Scheduling Timed Jobs [7] covers OS-owned schedules and sleep behavior. Calendar jobs can run on wake after a missed sleep-time fire; a powered-off machine does not replay that fire immediately.

These are archived Apple guides. Use the installed macOS manual pages to validate current launchd details. They document the supervisor mechanism, not permission to bypass an application's execution restrictions.

5. Approval extensions have a hard limit

Plugins — Approval transports [4] explains ctx.register_approval_transport, request/digest binding, bounded timeouts and deny-by-default behavior. It explicitly says transport changes where approval is shown, not authorization policy. Hardline commands are blocked before the transport callback.

What this research does not establish

No single guide was found that proves a complete macOS solution combining carried exact-stable merges, dashboard reconfiguration, chat-bound approval, safe worker containment and durable results.
The proposed architecture is a supported OS-owned maintenance executor with a narrow chat request/approval layer and native updater receipts. This is a design direction, not a validated deployment recipe.
A denied lifecycle action cannot be made permitted merely by moving it into a plugin or changing its approval presentation.