p24-infra Docs

w4-health-check-egress

3 min read

w4.pinbox24.com health-check — egress decision

Issue: #3331 (consolidates #2706, #2708, #3016, #3043, #3167, #3250) Decision date: 2026-07-08

Problem

A scheduled “w4.pinbox24.com health-check” routine was running inside a Claude Code Remote sandbox. That sandbox enforces an outbound-egress policy: every CONNECT tunnel to api.w4.pinbox24.com:443 was rejected by the environment’s own agent proxy with HTTP/1.1 403 Forbidden — the TLS handshake never happened and the target server was never reached.

Result: the routine returned HTTP 000 on every run and filed an “inconclusive / cannot verify” issue each time. Six such duplicates accumulated (#2706, #2708, #3016, #3043, #3167, #3250). None were real production incidents — they were all the same environment-policy limitation.

Diagnostic signature (from the duplicates):

$ curl -v https://api.w4.pinbox24.com/api/i18n/langs
* Establish HTTP proxy tunnel to api.w4.pinbox24.com:443
< HTTP/1.1 403 Forbidden
* CONNECT tunnel failed, response 403
curl: (56) CONNECT tunnel failed, response 403

$HTTPS_PROXY/__agentproxy/status confirmed recentRelayFailures with kind: connect_reject — i.e. the block is the sandbox proxy, not pinbox24.

Decision — reroute onto a host that has egress

The w4 up-check now runs from the existing .github/workflows/health-check.yml workflow (health-http job), which executes on GitHub-hosted ubuntu-latest runners. Those runners have full outbound internet egress and can reach api.w4.pinbox24.com. The workflow already runs every 2 hours (cron: "0 */2 * * *") and already wires results into Discord reporting and the shared server-down GitHub issue.

The check itself:

curl -s -o /dev/null -w "%{http_code}" \
  --connect-timeout 10 --max-time 15 \
  "https://api.w4.pinbox24.com/api/i18n/langs"
# 2xx = v42-prod backend answering (same unauthenticated up-signal the w3/w4
# MongoDB app-password rotation routine uses).

This is the single authoritative w4 health signal going forward.

Why not allowlist the host in the sandbox egress policy?

Option (b) — adding api.w4.pinbox24.com to the sandbox allowlist — was rejected:

  • The egress policy is an Anthropic-side environment control, not something this repo can configure or guarantee across sessions.
  • Running network health probes from inside an LLM agent sandbox is the wrong tool regardless — a scheduled CI job on a host with egress is the correct, observable, self-alerting mechanism.

Action for humans — retire the sandbox routine

The old scheduled “w4 health-check” routine lives in the Anthropic /schedule cloud-routine registry, not in this repository, so it cannot be deleted by a PR. Disable that cloud routine (via /schedule management) so it stops re-filing egress-blocked duplicates. GH Actions health-check.yml now covers w4 authoritatively.

If a new “w4 health-check cannot reach target — 403 CONNECT” issue appears after this date, it means the sandbox routine is still enabled — disable it and close the issue as a duplicate of #3331.

Graph View

Backlinks