---
id: fleet/plugins-update-restarts-every-sidecar-so-the
title: '`plugins:update` restarts every sidecar, so the report understates what moved'
theme: fleet
status: open
created: 2026-08-21
date_source: stated
order: 7
---

**`bun run plugins:update` restarts sidecars itself**, printing `sidecar: started` per plugin. On `alpha`
that is twelve processes bouncing during step 3 — before the plan's own restart step, and not something
any plan asked for.

Nothing is broken and this is not new behaviour. The problem is honesty: a deploy report whose "restarted"
column reads `officer` is describing one restart when thirteen happened, and the whole value of these
reports is that they can be trusted about what moved.

Two ways out, and they are not the same decision:

- **Make the report accurate** — the plan format grows a note, or the commander reads `restart_time` for
  every process rather than only the ones it restarted. Cheap, and it is the honest minimum.
- **Make the script not do it** — a `--no-restart` flag, with the deploy restarting what the plan names.
  That is the better shape (a plan that says "restart `officer` only" should mean it) but it is a change
  to something that works, and a plugin whose sidecar is not restarted after an update may well be broken
  in a way nobody notices until later.

Do the first regardless. The second is a real design call.