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

[sven.den.hartog]

I get this error when I add allowlist network policy with our production domains to an agent with a shell tool (using the openai agent sdk):

```
An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID req_3b0917dca27342dda56901e1a1c05306 in your message.
```

It does not occur when network policy is disabled. The domains in allowed_domains are in Container network mode in the data controls in platform.openai.com. Another thing to note is that it was still working on Feb 26.

[sven.den.hartog]

Here is a minimal set of instructions to reproduce the problem:

1. Add a domain (e.g. “google[dot]com” as in the code snippet) to platform.openai.com > Data control > Hosted tools > Container network mode > allowlist

2. Run the command below

3. Result:
   Error code: 500 - {‘error’: {‘message’: ‘An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID req_XXXXX in your message.’, ‘type’: ‘server_error’, ‘param’: None, ‘code’: ‘server_error’}}

curl -sS https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.2",
    "input": "Use shell tool and run: curl google.com",
    "tools": [
      {
        "type": "shell",
        "environment": {
          "type": "container_auto",
          "network_policy": {
            "type": "allowlist",
            "allowed_domains": ["google.com"]
          }
        }
      }
    ]
  }'

[_j]

You must “preauthorize” every URL that will be employed manually. It seems you found Container network mode → allow list for your organization. You also must “save” there.

https://platform.openai.com/settings/organization/data-controls/hosted-tools

Also, ensure that you consistently use only the domain name or subdomain, and not a http prefix - which neither the input into the allowlist or input into the platform site’s shell tool will warn about - you’ll just get more failures.

“Googling” is not scrape-able or accessible by bot, generally, if you thought the AI could search, which it seems you are trying. When OpenAI has a pay-per-use internet search, consuming from a competitor might not be facilitiated, either. If you have a Google-hosted resource, see that it can be retrieved by a scripted “GET” first.

I’ve used the internet access to update wheel modules and get blob storage files, to report that it does generally work.

[sven.den.hartog]

The Google domain is just an example but it should still work (it should just return some html to the llm).

My use case involves having a skill for using our production rest API so our domain is trusted and should be accessible from the shell container. I added it to the list of allowed domains (in the place of the Google url in curl snippet) in the request but also in the allowlist in the admin dashboard on platform.openai.com. No http prefixes etc. I also tested creating a container and then referencing the container in the shell tool but that also gave the same error.

Could you check if it’s still working right now? Because it seems that it broke on February 26. I had no code changes but suddenly it broke.

[_j]

Reporting working → non-working in the same call type is an important notation.

Preface: use a supported AI model → gpt-5.2

1. Setting Data Controls in OpenAI platform:

2. Creating hosted shell tool in Responses playground:
   

   

3. Employing shell tool with auto-container.
   

   

4. Confirmation - one more thing is down on the API:

“Get code” snippet.

  "tools": [
    {
      "type": "shell",
      "environment": {
        "type": "container_auto",
        "network_policy": {
          "type": "allowlist",
          "allowed_domains": [
            "pypi.org",
            "files.pythonhosted.org"
          ]
        }
      }
    }
  ],

[sven.den.hartog]

Thank you for confirming. I was afraid that either my org was shadow banned or it was some very obscure setting I was missing.

[sven.den.hartog]

Some extra information: you don’t have to instruct the llm to use the shell tool. It just errors whenever you have the allowlist in the container params.

[sven.den.hartog]

Does anyone know the ETA of something like this being fixed? This is holding up our company badly and I can’t imagine that we are the only ones using this feature. There should at least be a notice somewhere that it’s broken atm. Thank you.

[OpenAI_Support]

Hello,

We re-tested this on our side and weren’t able to reproduce the error, so it may have been a temporary issue rather than something caused by the network allowlist itself.

Could you let us know if you’re still seeing the problem? If so, does it only happen when network_policy.type="allowlist" is enabled, or do you also see it without the allowlist?

If it’s still happening, please send a recent request ID and approximate timestamp so we can investigate further.

[FaridKia]

Hitting the same symptom on the openai-agents SDK 0.14.1 with the hosted shell tool in container_auto. Every shell-tool curl from inside the container exits with curl: (7) Failed to connect to proxy port 8080 after ~1000ms, even though the per-run network_policy allowed_domains host is also on the org dashboard allowlist (bare hostname, saved).

Concrete data in case it’s useful:

• Request ID: resp_0a3f1c690bbd22eb0069ef43e7c6ec8194ba88fd2b3d065f64
• Timestamp: 2026-04-27 06:09 UTC
• Per-run policy: type=allowlist, single hostname in allowed_domains
• memory_limit=1g, max_turns=12

On your specific question — we haven’t yet rerun with network_policy.type="disabled". Just shipped an env-var toggle for that A/B test on our side; will follow up here with the result.

There’s another open thread on this forum (the one whose title starts with “Hosted Shell container cannot clone from a public git host even though that host is allowlisted in network_policy”, March 26) reporting the same proxy port 8080 failure mode. A community user there pointed at the cause: the container auto-sets HTTP_PROXY and HTTPS_PROXY to the in-container proxy daemon, and that daemon is the unreachable thing. Bypassing the proxy by unsetting HTTP_PROXY and HTTPS_PROXY and calling curl with --noproxy '*' (or git with -c http.proxy=) makes outbound calls land — destination is on the allowlist, the broken hop is just the proxy-env routing. Flagging in case it helps narrow down whether this thread and that one are the same underlying issue.

[FaridKia]

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.

[OpenAI_Support]

Hello, we’re able to reproduce this issue on our end, and we’ve reached out to our API team for further investigation.

We’ll keep you updated as we learn more.

[OpenAI_Support]

Hello, we have deployed a fix for this.

Let us know if you are still experiencing this.

[FaridKia]

Thanks for the update. We re-tested today, and the broad hosted-shell networking outage does look mostly fixed for our project, but we are still seeing one host-specific failure.

Setup:

• OpenAI Agents SDK for Python: openai-agents 0.14.1, openai 2.32.0
• ShellTool(environment=container_auto)
• Per-call network_policy={“type”: “allowlist”, “allowed_domains”: []}
• Model: gpt-5.4, reasoning effort low
• Each target host is also listed in our project Container network mode allowlist
• Test: one curl per cell, with a 20 second timeout, recording HTTP code, curl exit code, and a small body preview
• Date: 2026-05-04

Results:

• raw dot githubusercontent dot com: 2/2 attempts returned HTTP 200 with body. Working.
• github dot com: 1/1 returned HTTP 302, which is the expected GitHub redirect. Working.
• our own API host: 1/1 connected successfully; the server returned the expected auth 403. Working from a network perspective.
• api dot github dot com, path /zen: repeated attempts failed with curl exit 7 / HTTP 0. Not working.

Recent failing response IDs for api dot github dot com, path /zen:

• resp_0ff57af9e04d94c40069f903c97c6881979ea9826fe83a3786
• resp_0124dec28939b6e90069f903fc71108196bfad6ec6aefe45ed

So the original failure mode we saw earlier, where sandbox networking failed broadly across hosts, appears resolved. The remaining issue seems narrower: api dot github dot com still fails at the TCP/connect layer, while github dot com and raw dot githubusercontent dot com work in the same setup with the same SDK call pattern and allowlist configuration.

We have verified that api dot github dot com is explicitly present in the project Container network mode allowlist. We also do not see a Responses API server_error for these runs; the call completes and the agent reports curl’s connection failure from inside the shell tool output.

[OpenAI_Support]

Thanks for confirming the broader issue is resolved. For the specific issue you’re still seeing, please contact support through help.openai.com so we can investigate further and assist.