Regeneration onto a fixed release runs inside the agent session, so a boot-blocking defect leaves consumers with no self-heal path

[tend-agent]

A defect that stops the agent booting takes out the mechanism consumers would use to pick up its fix, so every consumer stays broken until a human runs uvx tend@latest init by hand. Today's bubblewrap outage is the third instance of the precondition in nine days, and the first where a tend session in this repo could observe the whole thing.

The loop

macros.yaml.j2 states the design: the action ref pins to an immutable release tag, and "consumers move forward via the nightly uvx tend@latest init regen pulling a newer generator, which restamps a newer tag as a reviewable diff in their own repo." That regen runs inside the agent turn — nightly/SKILL.md has the nightly session call nightly_workflow_update.py prepare, edit the prepared worktree, run uv tool run tend@latest init in it, and ship — so it needs a booted agent.

When the defect is in the boot path itself, the agent never starts, the nightly never regenerates, and the pin never moves. There is no other path: tend-nightly is the only workflow that regenerates, and nothing in the generated workflows runs init outside the sandbox.

Why this isn't a one-off

Three fleet-wide boot failures since 2026-09-08, each killing sessions before the first turn:

When	Cause	Recovered by
2026-09-08	0.2.2 shipped shared/steps/install-uv.sh non-executable across the sandbox boundary	0.2.4 + hand regeneration
2026-09-08	0.2.3 published an action cache missing shared/steps/sandbox_runtime.mjs	0.2.4 + hand regeneration
2026-09-17	bubblewrap 0.9.0-1ubuntu0.2 (CVE-2026-87766) made a 0o711 bind-destination parent unopenable — #1277, #1279	0.2.10 + hand regeneration (#1283)

The first two are release defects, where "don't ship it" is at least a conceivable answer. The third isn't: nothing in tend changed. The Ubuntu archive moved under a running fleet, so no amount of pre-release care would have prevented it, and rolling the pin backwards wouldn't have helped either — Ubuntu keeps one version per pocket and the superseded package was already gone.

In each case this repo recovered in under an hour because a human was watching. A consumer whose maintainer is asleep recovers whenever they next look at their Actions tab.

What it costs

Little in tokens — these failures die before the first turn, so today's eleven cost $0 in model spend. The cost is the outage itself: from the first confirmed failure to the regeneration onto 0.2.10, every tend-review, tend-triage, and tend-notifications event was dropped rather than deferred. #1279 sat unanswered for 49 minutes; #1282's review died and was recovered only because this daily sweep looked for it; #1277, #1281, and #1283 — including the release that ended the outage — merged with no bot review at all. In a consumer repo the same window is however long it takes someone to notice, and the outage tracker filling with rows is the only signal, in a repo whose whole point is that nobody has to watch it.

#1282 closes the detection half of this — a scheduled ci run watching from outside the sandbox. The recovery half is still open, and detection doesn't imply it: a consumer can know their bot is down and still have no automated way to move the pin.

The decision

Three shapes, and which is right is a call about the security model rather than a bug fix, which is why this is an issue and not a PR:

1. A runner-side regen step. tend-nightly runs uvx tend@latest init on the runner before the agent action, and opens the PR itself when the generated files change. Cheapest to build and it works with the agent completely broken — but it's a second regeneration path racing the agent's, and CLAUDE.md is explicit that deterministic YAML steps shouldn't reimplement work that happens inside an agent run. The counter-argument is that this is the one case where that rule's premise fails: the agent run is what's broken.
2. A separate minimal self-update workflow, with no bot token beyond contents: write and no consumer code in scope. Keeps the nightly's regen where it is and adds a path that survives the sandbox. More surface than (1).
3. Accept it. A fleet-wide boot failure is rare and loud, and arguably should have a human in the loop before every consumer's workflows are rewritten automatically. If this is the answer, the gap is documentation rather than mechanism — the outage tracker body could name uvx tend@latest init as the recovery when every row is a pre-agent failure, so the consumer maintainer who does look has the command without reading tend's source.

Option 3 is a legitimate answer and may be the right one; what's not defensible is the current state, where the loop exists and nothing says so.

How this was derived

From the tend-review-runs sweep over 2026-09-17T07:49:45Z → 19:41Z. This repository's run history brackets the break precisely: the last agent boot to succeed was tend-notifications 35246533937 at 16:25:52Z, and the first failure was tend-review 35261197467 at 18:49:47Z. Eleven runs failed at bwrap: Can't mkdir parents, all recorded in #1278. The nine tend-notifications ticks between 16:25 and 18:49 all report success because their pre-check early-exits before installing bubblewrap, which is why the Actions tab stayed green throughout.

The 0.2.2 and 0.2.3 rows are from the 2026-09-09 review-runs entry in #1125, which classified them Critical and structural and recorded 24 zero-turn failures across the two.

Note that #1277's "16:16" and "17:26" install timestamps are not from runs in this repository — no run started here between 16:03 and 16:25, or between 17:19 and 17:30 — so they are presumably from a consumer's history. The bracket above is this repo's own.

[tend-agent]

Not a bug and not a duplicate — the decision is the deliverable here, so triage's contribution is evidence that narrows it. Two findings change the option 1 vs 2 comparison.

Option 1 covers every boot failure the fleet has actually had. All three incidents died inside the composite-action step, with job setup already complete:

Incident	Run	Steps
0.2.2 non-executable install-uv.sh	34292075629	Set up job success → max-sixty/tend/claude@0.2.2 failure
0.2.3 action cache missing sandbox_runtime.mjs	34309552174	Set up job success → ...@0.2.3 failure
bubblewrap 0.9.0-1ubuntu0.2	35261197467	Set up job success → ...@0.2.9 failure

In all three, actions/checkout and astral-sh/setup-uv ran to success first, so a run: step ordered ahead of the agent step would have executed and could have opened the regeneration PR.

Option 1 does not cover an unresolvable pin. GitHub resolves every action a job references during Set up job, before the first step, so one bad uses: ref takes the job with it. Probe in tend-agent/tend-integration (branch since deleted): a job whose first step was run: echo and whose second was uses: max-sixty/tend/claude@0.0.0-does-not-exist failed in Set up job with Unable to resolve action — run 35268051388 — and the echo step never ran. Only a path that references no harness action, i.e. option 2, survives that class. No fleet incident has been in it and immutable release tags make it unlikely, but it is the one class where nothing inside a generated workflow can recover, which is worth weighing against option 2's extra surface.

Three mechanics that either option has to settle:

• The token decides whether the self-heal diff gets checked. A pull request opened with GITHUB_TOKEN creates pull_request runs in an approval-required state that a user with write access has to release, and pull_request_target — tend-review's trigger — is not in that exception list at all (docs). So option 2's "no bot token beyond contents: write" lands the regeneration with no CI and no bot review until a human clicks, which is the same human the outage was already waiting on. Handing it the bot PAT restores both and reinstates the surface option 2 exists to avoid.
• Branch ownership. nightly_workflow_update.py owns tend/update-workflows, and ship updates whatever PR is riding that branch. A second regeneration path sharing it is the concrete form of the race in option 1's counter-argument: it needs its own branch, or the agent's path has to yield when the runner-side one has already shipped.
• uv on the runner is not a given. setup: is consumer-owned — this repo's .config/tend.yaml happens to supply astral-sh/setup-uv, and a consumer's need not — so a generated uvx tend@latest init step has to install uv itself rather than inherit it.

On option 3: report_failure.py's outage body names no recovery command today, and that line is compatible with all three options rather than being only option 3's answer. I left it unwritten because which option wins decides whether it is the mechanism or a footnote to one.

[max-sixty]

One implementation note for option 3's parenthetical — having the outage
tracker name the recovery. The step that would carry it already exists and
already runs in the right place: Report failure in claude/action.yaml is
gated on failure() and runs outside the agent, which is why it kept firing
through today's outage when everything downstream of the turn did not. It
holds github_token, so the one API read that says whether a newer release
exists is available to it.

Two things to get right if it is written:

• github.action_ref does not interpolate inside a composite action step's
  run: body — it resolves only in that step's env:
  (actions/runner#2473,
  #2525). claude/action.yaml
  currently passes that step only BASH_ENV and GITHUB_TOKEN, so the running
  version has to be added to its env: or derived from __file__ in
  report_failure.py. Either is a line, but writing the interpolation into the
  run: body yields an empty string rather than an error.

• The remedy line is only correct when the installed version is behind. On a
  current consumer a boot failure means something else, and telling them to
  regenerate would send them the wrong way.

What makes this worth the line at all is the third-party case. A consumer we
do not own gets an issue that accumulates run links, and the enrichment that
would name the cause is itself an agent step. They have to derive the cause
and the remedy from our source, or wait for us to notice.

This was written by Claude Code on behalf of max-sixty

[tend-agent]

Written as #1288, since the line holds under all three options and the third-party case doesn't wait on the decision. Both notes are in it.

The version comes through env: in each harness action rather than off __file__, with a test_repo_pins case asserting it per harness — the failure mode this guards is a silent one, since an empty value looks exactly like a current pin.

The "only when behind" point turned out to have a second half: the release that ends an outage normally lands while the outage is still running, so a body-only note would have said nothing during the 2026-09-17 incident — 0.2.10 didn't exist when #1278 was filed. So the note is computed per run and rides the first row posted after the pin falls behind, once per tracker. Strictly behind, so a consumer on the newest release is told nothing.

That leaves options 1 and 2 as the open decision, now without the documentation gap riding on it.