Package installation broken in ChatGPT containers - package mirrors return HTTP error 503

ChatGPT Bugs
, , , ,
1

The gateway used for package manager mirrors in the container tool consistently returns HTTP 503 Service Temporarily Unavailable. So package installation via apt, pip, cargo, npm etc is now unavailable in container sessions. This blocks a lot of development tasks, and makes it very annoying to run programs with external dependencies.

URL: https://packages.applied-caas-gateway1.internal.api.openai.org

Relevant built-in container script: /usr/local/init_scripts/caas_package_mirror.sh

Environment

  • Product: ChatGPT
  • Mode: Chat
  • Model: GPT-5.6 Thinking
  • Tool: container

Is anyone else experiencing this as well? Can anyone reproduce this?

Steps to reproduce

In a ChatGPT container environment:

curl -sS -o /dev/null -w '%{http_code}\n' https://packages.applied-caas-gateway1.internal.api.openai.org/

Result:

503

The Artifactory health endpoint also fails:

curl -i https://packages.applied-caas-gateway1.internal.api.openai.org/artifactory/api/system/ping

Result:

HTTP/2 503
server: nginx
content-type: text/html
content-length: 190

After you’ve set the mirrors up with caas_package_mirror.sh, apt also returns 503.

apt-get -o APT::Update::Error-Mode=any update

Result:

Err:1 https://packages.applied-caas-gateway1.internal.api.openai.org/artifactory/debian-public ...
  503 Service Temporarily Unavailable [IP: 10.224.0.68 443]

E: Failed to fetch ...
E: Some index files failed to download.

Expected behaviour

The internal package gateway should proxy requests to the configured package repositories.

Actual behaviour

Every tested HTTPS path returns the same generic 190-byte nginx response:

HTTP/2 503
server: nginx
content-type: text/html
content-length: 190

<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx</center>
</body>
</html>

Also checked the following:

  • The gateway root, health endpoint, and all package repositories consistently respond with HTTP 503
  • The hostname resolves inside the container (to 10.224.0.68)
  • TCP port 443 is reachable
  • TLS 1.3 negotiation succeeds
  • The cert validates successfully
  • Both authenticated and unauthenticated requests return the same response.
  • Same error with both HTTP/2 and HTTP/1.1
  • Using a fresh container and fresh conversation doesn’t fix it
  • Azure Storage endpoints in the container hosts file were reachable
2

I’ve been having similar issues since late last night. It’s super annoying and I’ve been ground to a halt on my project.

3

That sucks. In a way I’m glad to hear it’s not just me, but I’m sorry you’re dealing with it too.

A painful alternative: get ChatGPT to write a script which prepares all your dependencies offline, and zips them up. Make sure the zips split every 500 megabytes or you’ll be blocked from uploading them to ChatGPT. You can then create a project, upload all the zip files to the project and then any conversations in that project can extract them and install the packages inside.

In the meantime I’ve also set up an hourly scheduled task to notify me when it becomes accessible again.

4

I’ve been doing the same thing as you. Using a script to zip it up offline. That’s a great ideas to give you an update every hour until it’s back up. I’m gonna do that too.

5

I’m seeing the same issue with the exact same internal gateway:

https://packages.applied-caas-gateway1.internal.api.openai.org

npm ping consistently returns HTTP 503, and switching to a fresh conversation or container does not help. I have already reported it to OpenAI Support with logs, timestamps, screenshots, and a screen recording. This clearly appears to be a shared container package-mirror outage, not a project-specific problem.

6

Hey y'all, sorry for the late response.

Thanks for the detailed diagnostics. Successful DNS and TLS checks followed by the same 503 response across multiple package endpoints suggest an issue with the shared package gateway or its upstream service. That would also explain why fresh containers didn't help.

Building on the offline workaround already shared: for Python packages, you can download the required packages and dependencies on another machine, then upload them and install from the local files. Make sure they match the container's Python version, operating system, and CPU architecture; note that packages downloaded for Windows or macOS may not work in the container.

Once the compatible package files are uploaded and extracted, you can use:

```

python -m pip install --no-index --find-links=/path/to/wheels -r requirements.txt

```

This avoids contacting the unavailable package index. Packages that require additional system libraries may still need those dependencies, so running the task locally is another temporary option.

If the issue persists, please open a new topic with the latest details.

Felenciya