---
id: fleet/the-deploy-commander-cannot-finish-its-own-host
title: 'The deploy commander cannot finish its own host'
theme: fleet
status: open
created: 2026-08-21
date_source: stated
order: 5
---

**The deploy commander cannot finish its own host, so one machine is always a build behind until somebody
restarts it by hand.** After `2026.08.21.03` that skip was two releases deep on `officer-dev` —
`restart_time` unchanged at 155 — with the code for both sitting on disk.

The skip itself is correct and should not be removed. The commander is a session inside
`officer-claude-code` on that machine; restarting `officer` there ends the rollout mid-flight, and it is
not hypothetical — a manual deploy on 2026-08-21 had to leave that one sidecar alone to survive writing
its own report. Restarting only `officer` and leaving the sidecar would technically work and is worse: it
puts one host in a state nobody chose, a step behind the rest, discovered later.

So the question is what finishes it, and there are three honest answers:

- **A deferred restart the platform runs after the session ends.** Cheapest. The commander writes a
  one-shot request, something outside the agent's process honours it, and the report says a restart is
  pending rather than outstanding. Needs a thing that is not the agent and not `officer` — `at`, a systemd
  transient unit, or PM2 itself.
- **A second machine deploys this one.** Cleanest and needs no new mechanism at all: any other host's
  commander has no reason to skip `officer-dev`. Costs a second armed watcher and raises "who deploys the
  deployer" — two watchers must not both claim a release, which `scripts/deploy-claim.sh` already prevents
  per host but **not across hosts**, since the claim is local by design.
- **Leave it manual and make it loud.** The report already says "outstanding". A notification would close
  most of the gap for none of the work.

Not a decision to make from the code — it is the owner's call which of those three shapes he wants.