Responses API Outage: Hosted shell tool w internet access producing errors

Following up with sandbox-internal diagnostics. Built a small skill that gathers env vars, /etc/resolv.conf, /etc/hosts, ip route, and curls a multi-host matrix from inside the container.

Direct answer to your earlier question: the failure reproduces with network_policy.type="disabled" too — just with a different curl error.

A/B matrix (April 27 2026):

• allowlist, default curl → exit 7, “Failed to connect to proxy port 8080 after 3 s”
• allowlist, curl --noproxy '*' → exit 6, “Could not resolve host”
• disabled, default curl → exit 6, “Could not resolve host”
• disabled, curl --noproxy '*' → exit 6, “Could not resolve host”

Same pattern on six different hosts — our platform host, two GitHub-org hosts that are on the org-level allowlist, two more API hosts of ours, and a control host. Failure is universal, not host-specific or allowlist-specific.

Sandbox network shape from inside the container, with allowlist:

• HTTP_PROXY and HTTPS_PROXY (and lowercase variants) auto-set to the in-container proxy.
• NO_PROXY set to loopback addresses only.
• /etc/resolv.conf has a single nameserver — Azure WireServer DNS (resolves Azure-internal names only, not public hosts).
• /etc/hosts has a static entry mapping proxy to a private IPv4 in the same /28 subnet as the agent container.
• ip route shows one route — the local /28 only. No default gateway, no path to the open internet.

With disabled, the proxy env vars are unset entirely; everything else is the same.

So the proxy sidecar in the agent’s /28 is the entire egress for both DNS and HTTP. When the daemon on it is unreachable, nothing inside the sandbox can reach anything outside.

The 3-second curl timeout to the proxy port (with no RST) is consistent with the daemon being down or with packets being silently dropped — not a 5xx-style daemon-up-but-broken.

Recent request IDs (April 27 2026, ~06:35–06:55 UTC):

• resp_0a3f1c690bbd22eb0069ef43e7c6ec8194ba88fd2b3d065f64
• resp_02da1b9c66ccc7f20069ef49c9618881948b7dab7aaae95450
• resp_0592f4e2555728c20069ef4b0f89bc8197afc96cd51122cf7f

Helpful next steps from your end if possible:

1. Whether the proxy sidecar is expected to be one container per session or shared across sessions.
2. ETA on a fix, or a recommended workaround for the meantime.

Happy to share the raw probe output if it would help.