{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihz7azifizsrm4vqv4umb53djqpy57gz63c4rr2sxwgavxkg5ff34",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mki242ybdtu2"
  },
  "path": "/t/responses-api-outage-hosted-shell-tool-w-internet-access-producing-errors/1375529#post_11",
  "publishedAt": "2026-04-27T12:05:03.000Z",
  "site": "https://community.openai.com",
  "textContent": "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.\n\nDirect answer to your earlier question: the failure reproduces with `network_policy.type=\"disabled\"` too — just with a different curl error.\n\nA/B matrix (April 27 2026):\n\n  * `allowlist`, default curl → exit 7, “Failed to connect to proxy port 8080 after 3 s”\n  * `allowlist`, `curl --noproxy '*'` → exit 6, “Could not resolve host”\n  * `disabled`, default curl → exit 6, “Could not resolve host”\n  * `disabled`, `curl --noproxy '*'` → exit 6, “Could not resolve host”\n\n\n\nSame 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.\n\nSandbox network shape from inside the container, with `allowlist`:\n\n  * `HTTP_PROXY` and `HTTPS_PROXY` (and lowercase variants) auto-set to the in-container proxy.\n  * `NO_PROXY` set to loopback addresses only.\n  * `/etc/resolv.conf` has a single nameserver — Azure WireServer DNS (resolves Azure-internal names only, not public hosts).\n  * `/etc/hosts` has a static entry mapping `proxy` to a private IPv4 in the same /28 subnet as the agent container.\n  * `ip route` shows one route — the local /28 only. No default gateway, no path to the open internet.\n\n\n\nWith `disabled`, the proxy env vars are unset entirely; everything else is the same.\n\nSo 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.\n\nThe 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.\n\nRecent request IDs (April 27 2026, ~06:35–06:55 UTC):\n\n  * `resp_0a3f1c690bbd22eb0069ef43e7c6ec8194ba88fd2b3d065f64`\n  * `resp_02da1b9c66ccc7f20069ef49c9618881948b7dab7aaae95450`\n  * `resp_0592f4e2555728c20069ef4b0f89bc8197afc96cd51122cf7f`\n\n\n\nHelpful next steps from your end if possible:\n\n  1. Whether the proxy sidecar is expected to be one container per session or shared across sessions.\n  2. ETA on a fix, or a recommended workaround for the meantime.\n\n\n\nHappy to share the raw probe output if it would help.",
  "title": "Responses API Outage: Hosted shell tool w internet access producing errors"
}