Watchdog for the user's iPhone terminal tunnel (localhost.run reverse-SSH → ttyd-auth-proxy on 127.0.0.1:7681 → ttyd on 127.0.0.1:7682). VM-local processes die on container rebuilds; this runtime-side check keeps the tunnel alive. It also owns public-URL health probing.

Why probing lives here, not in the supervisor: the egress proxy password (in $HTTPS_PROXY) ROTATES per exec session. The long-lived tunnel supervisor's environment goes stale, so its own curls fail with 000 and would cause false-positive redials — and every redial mints a new public URL. Each run of this job gets a fresh environment, so its probes are trustworthy. The supervisor never probes the public URL; on genuine failure this job kills the ssh pid and the supervisor's main loop redials.

Each run, via exec: 1. Run ~/workspace/bin/recover-after-rebuild.sh — idempotent: re-provisions after a rebuild and ensures the tunnel supervisor is running (flock-guarded against double-start). If it had to restart the supervisor or provision, that is worth reporting. 2. Read the current URL: cat ~/workspace/tunnel/URL.txt. If empty or missing, the supervisor is probably still dialing — stay silent. 3. Confirm an ssh tunnel process is actually up: pgrep -f '[s]sh.localhost.run'. If none, the supervisor is mid-redial — write 0 to ~/workspace/tunnel/health.state and stay silent. 4. Probe the public URL: curl -s -o /dev/null -w '%{http_code}' --max-time 15 "<url>/". - HTTP 200 or 401 → healthy (401 is the auth proxy asking for credentials, which means the tunnel serves). Write 0 to ~/workspace/tunnel/health.state and stay silent. - Anything else (503, 000, timeout) → read the integer in ~/workspace/tunnel/health.state (missing file = 0), add 1, write it back. - If the counter reaches 2 (failing across ~10 minutes of runs): the tunnel is genuinely down. Kill the tunnel's ssh PID(s) — exact PIDs via pgrep -f '[s]sh.localhost.run', killed individually, never a broad pkill — to force the supervisor to redial. Write 0 back to the state file. Sleep 30s, re-read URL.txt, and report: the old URL was unhealthy after 2 consecutive failed probes, a redial was forced, and the new URL (or that the redial is still in progress and the new URL isn't published yet). 5. Also check the local stack: pgrep -f '[t]tyd -p 7682' and pgrep -f '[t]tyd-auth-proxy.py'. If either is missing, mention it in the report (the supervisor should restart them itself, but flag it).

Stay silent when everything is healthy — no routine "all good" messages. Report only: rebuilds/provisioning, supervisor restarts, forced redials (with old and new URL), or a missing stack component. Do not expose the ttyd password (in ~/workspace/.ttyd-pass) or the egress proxy password in any output. Do not edit MEMORY.md; routine observations go to the daily log ~/memory/YYYY-MM-DD.md.