[kcoopermiller]

Summary

• Bump deps/verifiers from 6d5edc7c to 29623317, which is verifiers main.
• In uv.lock, bump prime-tunnel from 0.1.14 to 0.1.17 and prime-sandboxes from 0.5.4 to 0.5.5, as the new verifiers requires. No other package changes.

Why

The env server's interception tunnels can get stuck. frpc keeps running and the tunnel still says connected, but requests never reach the env server. The tunnel answers each one with its 404 page, and the old watcher only checked whether the tunnel was still registered, so it never acted. Rollouts kept being sent to that tunnel and failed.

With this bump, the env server restarts frpc when requests stop reaching it. It also retires a server whose tunnel was deleted, fails that server's rollouts with TunnelError, and sends new rollouts to a replacement.

verifiers changes (6d5edc7c → 29623317)

• improvement(interception): keep tunnels serving with prime-tunnel (improvement(interception): keep tunnels serving with prime-tunnel verifiers#3041)
• improvement(interception): close the connection after each health answer (improvement(interception): close the connection after each health answer verifiers#3049)
• feat: add vf-run, a minimal in-process runner (feat: add vf-run, a minimal in-process runner verifiers#3047)
• chore: bump prime-sandboxes to 0.5.5 (chore: bump prime-sandboxes to 0.5.5 verifiers#3048)

Testing

With verifiers at 29623317, I ran rollouts in Prime sandboxes through prod tunnels and broke frpc mid-rollout:

Fault	Recovery	rlm rollouts
frpc frozen	Restart at 72 s	3/3
frpc killed	Restart at 7 s	3/3
frpc connected but not serving	Restart at 84 s	3/3
Only new connections hang	Restart at 86 s	3/3, and 2/2 on codex
No fault (rlm and bash)	0 restarts	6/6

In this repo:

• uv lock --check passes, using uv 0.12.6 so the lockfile format stays the same.
• Every verifiers import in src/ resolves at the new commit.
• I couldn't run the unit tests locally because litellm doesn't build on macOS, so this PR's CI is their first run.

Known limitation

Each recovery takes 60–90 s. During that window the tunnel returns its 404 page. rlm and hermes-agent rollouts survive it. Rollouts on other harnesses fail unless a retry rule for HarnessError or InterceptionError restarts them.

Note

This supersedes the verifiers part of #4344, which bumps to 076c364e. That commit is older than the current pin.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes rollout/env-server tunnel behavior in production; recovery can take 60–90s where the tunnel still returns 404, which may break harnesses without retry rules.

Overview
Updates uv.lock so transitive deps match the newer verifiers pin: prime-tunnel 0.1.14 → 0.1.17 and prime-sandboxes 0.5.4 → 0.5.5, including refreshed wheel/sdist URLs and the verifiers package’s minimum version specifiers in the lock.

That verifiers bump brings self-healing interception tunnels—when frpc is up but traffic no longer reaches the env server, the server can restart frpc, retire a bad tunnel, fail stuck rollouts with TunnelError, and route new work to a replacement instead of silently serving the tunnel 404 page.

^{Reviewed by Cursor Bugbot for commit 0d6a5e0. Bugbot is set up for automated code reviews on this repo. Configure here.}