refactor(install): give both pre-agent installers one retry window

[tend-agent]

Stacked on #907 — based on its branch, so the diff here is only the extraction. GitHub retargets this as the stack merges.

Problem

Raised in the review of #907: after #906 and #907 land, the same retry policy exists in two files with no shared source of truth. install-claude-binary.sh and install-proxy-uv.sh each carry ATTEMPTS=5, the same 5 * 2 ** (i - 1) + RANDOM % 10 backoff, the same timeout 60, and the same set -o pipefail-inside-bash -c requirement. The next adjustment to the window has to be found and applied twice, and the two rationale comments already differ in wording while describing one policy — which is how the windows drift apart.

The repo already has the mechanism: shared/steps/lib/run-issue.sh is sourced by both rate-limit-preflight.sh and report-failure.sh.

Change

shared/steps/lib/retry.sh holds retry_install LABEL COMMAND — the loop, the backoff, the jitter, and the set -o pipefail that both callers' curl | sh shape depends on. Each caller keeps its own one-line rationale for why it fetches what it fetches; the window's rationale lives once, in the lib.

The review flagged the sandbox boundary as the unverified part, and it is real: install-claude-binary.sh runs its loop inside sudo -u "$SANDBOX" env … bash <<'EOF', and nothing grants the sandbox UID read access to the action's own checkout — setup-sandbox.sh grants traversal (o+x) on the workspace's ancestors only, and the action lives elsewhere under _actions/. So the lib is not sourced by path from inside the heredoc. It is concatenated onto the front of the script the sandbox bash reads from stdin:

cat "${SCRIPT_DIR}/lib/retry.sh" - <<'EOF' \
  | sudo -u "$SANDBOX" env HOME="$AGENT_HOME" … bash
set -euo pipefail
retry_install "claude $CLAUDE_VERSION" \
  "curl -fsSL https://claude.ai/install.sh | bash -s -- '$CLAUDE_VERSION'"
EOF

The file is read on the runner side of the privilege drop, so sandbox read access never enters into it, and the privilege drop itself is unchanged — same sudo -u, same env, same pinned XDG dirs. install-proxy-uv.sh runs as the runner and sources the lib normally.

Behaviour is unchanged on both paths: five attempts, 5/10/20/40s plus 0–9s jitter, ::error::failed to install <label> after 5 attempts on exhaustion, one fetch and no sleep on the happy path.

Tests

No new tests — the eight added by #906 and #907 already pin the contract behaviourally on both callers (attempt count, backoff floors, the exhaustion message, the no-sleep happy path), and they pass unmodified against the extracted lib. That is the point of the pair: the shared window is now asserted twice, from opposite sides of the sudo boundary.

Full generator suite: 387 passed. shellcheck -S warning clean on both scripts and the lib.

If you'd rather not review three

The end state is what matters, not the split — squashing this into #907 loses nothing.

[tend-agent]

Self-review — the extraction holds up. I checked the sandbox path locally rather than trusting the shape: exhaustion still exits 1 through the new pipeline (the outer set -eo pipefail carries the sandbox bash's status), and the eight tests from #906/#907 pass unmodified against the lib. Two things outside the diff.

A third pre-agent installer isn't on the shared window. codex/action.yaml's Install Codex CLI step runs npm install -g "@openai/codex@..." bare, and that action's Report failure is gated on steps.codex.outcome == 'failure' — the exact shape retry.sh's header describes. An npm registry blip loses a codex run the way a CDN blip lost a claude one. It can't just call retry_install as-is: it's an inline run: block, so it needs extracting into shared/steps/ first. Follow-up rather than something to fold in here, but worth naming while the reasoning is fresh — I can open it.

The lib's rationale has a known expiry. retry.sh explains the wide window with "loses the run with no outage row (Report failure is gated on the agent step's own outcome)". #857 rewrites that gate to failure() && steps.security.outcome != 'failure', which does file a row for a pre-agent failure. Whichever of the two lands second should drop that parenthetical — the window's real justification is the lost run, not the missing row. The extraction at least makes it one copy to fix instead of two.

[tend-agent]

Both points actioned.

The third installer — filed as #909 rather than folded in, for the reason the review gives: it's an inline run: block, so it needs extracting into shared/steps/ before it can call retry_install at all. Writing it up turned up one thing worth settling before anyone wires it: retry_install hardcodes timeout 60, which fits a curl | sh fetching one installer script but not necessarily a global npm install resolving a dependency tree. I haven't measured @openai/codex on a cold runner, so the issue asks for that measurement first — dropping it under the current lib unmeasured would convert slow installs into failures, which is the opposite of the point.

The expiring rationale — fixed here in 1b63e55 instead of leaving it for whichever of this and #857 lands second. The parenthetical is gone; the header now justifies the window by the lost run and says so explicitly:

The lost run is what justifies a window this wide, independent of how the failure is reported afterwards.

That last clause is deliberate — it's what stops a future reader re-deriving the parenthetical from whatever the gate happens to say then. Two test docstrings from #906/#907 carried the same claim (leaves no outage row, loses the run with no outage row); both are updated the same way, so the expiry is gone from all three copies rather than just the lib. Now neither PR has to know about the other.

387 passed, shellcheck -S warning clean on the lib and both callers.