proxy: the mitmproxy cache warm is the fourth pre-agent reach, and it's not on the retry window

[tend-agent]

lib/retry.sh's header (as of #910) enumerates the pre-agent third-party reaches as three — install-claude-binary.sh (claude.ai), install-proxy-uv.sh (astral.sh), install-codex-cli.sh (registry.npmjs.org). There is a fourth, and it is not on the window.

proxy/setup-sandbox.sh:319 warms the uvx cache before backgrounding the proxy:

MITMPROXY="mitmproxy==${MITMPROXY_VERSION}"
UVX="${TEND_UV_DIR}/uvx"
"$UVX" --from "$MITMPROXY" mitmdump --version >/dev/null

On a cold UV_CACHE_DIR that resolves and downloads mitmproxy from PyPI. The script runs under set -euo pipefail (line 33), so a failed resolve exits non-zero, and the calling step — Set up credential-isolation sandbox, claude/action.yaml:205 — runs three steps ahead of Run Claude at line 273. A PyPI blip there costs the whole run having done none of the work the trigger asked for: exactly the failure #906/#907/#908/#910 exist to close, on the one remaining reach.

Why the cache doesn't cover it

The actions/cache key is version-scoped — tend-mitmproxy-${{ runner.os }}-${{ inputs.mitmproxy_version }} (claude/action.yaml:203) — so a miss isn't a rare event, it's scheduled. Every mitmproxy_version bump misses on the first run for every workflow, and the weekly bump PR is the moment a PyPI blip is most expensive: it would redden the PR that carries the security-relevant pin. Evicted entries (7-day idle, or the repo's 10 GB cap) miss the same way.

Proposed fix

retry_install is sourceable from proxy/setup-sandbox.sh the way the installer scripts source it — the lib is at shared/steps/lib/retry.sh and the script already resolves ${ACTION_PATH}. So:

. "${ACTION_PATH}/shared/steps/lib/retry.sh"
retry_install "mitmproxy ${MITMPROXY_VERSION}" \
  "'$UVX' --from '$MITMPROXY' mitmdump --version >/dev/null"

Two things to check when picking it up, neither settled here:

• The 60s timeout. Unlike the npm install measured in fix(install): give the codex CLI install the same retry window #910 (2.6-3.1s, prebuilt binary), a cold mitmproxy resolve pulls a real dependency tree; claude/action.yaml:196-197 calls it a "~20s resolve" but that figure isn't dated and predates several version bumps. Time it on a runner with a cleared cache before assuming 60s is generous. If it isn't, that's the case for the optional third parameter (retry_install LABEL COMMAND [TIMEOUT]) that codex: the CLI install is the one pre-agent installer not on the shared retry window #909 raised and fix(install): give the codex CLI install the same retry window #910 declined — npm didn't need it; this might.
• The backgrounded mitmdump on the next line is a separate question. It's the same PyPI reach on a cache miss, but it's nohup'd with a readiness wait after it, so a retry there isn't the same shape and shouldn't be folded in without thinking about the wait.

Also update lib/retry.sh's header enumeration from three reaches to four.

Raised in the review of #910.

[tend-agent]

Fix in #912, stacked on #910 since that's where the lib it sources lands. CI is green.

Both open questions resolved by measurement on a GitHub-hosted runner (2026-08-09, uv 0.12.3, pinned mitmproxy==12.2.3):

60s is generous, not tight. A genuinely cold UV_CACHE_DIR resolve — 43 packages, ~100MB downloaded — takes 2.2s (2.28 / 2.26 / 2.27 / 2.24 across four runs); a warmed cache serves it in 0.51s. The ~20s resolve figure in claude/action.yaml was both undated and wrong, so #912 corrects it. No third TIMEOUT parameter needed — the case #909 raised and #910 declined stays declined.

The backgrounded mitmdump doesn't need its own retry, because the warm's retry already covers it. The launch shares UV_CACHE_DIR, and a cache warmed by the line above serves the same --from invocation with no network at all — uvx --offline --from 'mitmproxy==12.2.3' mitmdump --version succeeds against it. Once the warm succeeds, PyPI is off the launch path, so the nohup-plus-readiness-wait shape never has to be retried. That reasoning is recorded in the comment at the warm rather than left for the next reader to re-derive.

One asymmetry worth naming, since a reviewer will notice it: the fourth site doesn't get the behavioural suite the three installers have. setup-sandbox.sh creates the sandbox user, chowns the workspace and installs a CA before it reaches the warm, so faking a path down to that line would assert more about the fakes than about the script. Instead #912 pins the two things that are actually new at this site — that the ${ACTION_PATH} source path resolves (a wrong one loses every run under set -euo pipefail, not just the ones that hit a blip), and that the warm is an argument to retry_install rather than a bare command. What the window itself does stays covered by the installer suites.

lib/retry.sh's header now enumerates four reaches.