---
id: fleet/the-watcher-loop-is-rewritten-by-an-agent-every
title: 'The watcher loop is rewritten by an agent every time it arms'
theme: fleet
status: open
created: 2026-08-21
date_source: stated
order: 6
---

**The watcher loop is rewritten from scratch by an agent every time one arms**, so its correctness is
re-rolled on every arming. The first one on 2026-08-21 was careful, logged honestly, set a `timeout` on
its network call, routed stderr away from the JSON it was parsing — and still contained an unbounded
retry, because the obvious way to ask "have I done this release" is to test the `.done` file, and that
file only exists on **success**.

`scripts/deploy-claim.sh` fixed that one instance by moving the rule into code. The general problem is
untouched: the next loop can get something else subtly wrong, and nothing will notice until it costs
money or misses a release.

Things a platform-owned loop would make constant rather than re-derived, all of them learned by an agent
getting them wrong once:

- Claim the version before spawning anything.
- `OFFICER_ROOT` set explicitly — it is **empty** in the sidecar's environment, so the lock path resolves
  to `/data/deploys` and every release looks permanently undeployed.
- stderr kept out of the `stream-json` stream, or the `claude.ai connectors are disabled` warning corrupts
  the first `jq` parse.
- `jq --unbuffered`, or the job panel shows nothing for twenty minutes and reads as hung.

The tension worth naming: an agent writing its own loop is also the reason this worked at all on the first
night, from a prose description, with no watcher feature built. A fixed script is more correct and less
general. The likely answer is a **script the loop calls** rather than a script that replaces it — which is
what the claim rule already is, and it could absorb the four items above the same way.