Hi folks — I’m trying to run .NET integration tests that rely on Testcontainers Cloud (TCC) from Codex Cloud. The TCC agent starts, discovers zones, obtains a worker lease, but then fails to connect:
... Obtained a worker ... endpoints=["tcp://<IP>:22","wss://<IP>:443/ws/22","ws://<IP>:80/ws/22"]
... ERR Connection failed: ssh client creation: connect to worker: all endpoints failed to connect
... restart in 9.9s
Abridged agent log shows discovery and leasing succeed, but the subsequent SSH/WebSocket connection to the worker cannot be established.
What I’ve tried
-
TC_CLOUD_CONCURRENCY=1 -
TC_CLOUD_PREFER_WEBSOCKET=true(to avoid port 22) -
Removing stale
tc.host/docker.hostentries before each run -
Waiting for the agent to be ready and using the agent‑written
docker.hostendpoint for DotNet.Testcontainers -
Ensured Testcontainers token is a service account, not user auth
Environment
-
Codex Cloud run with internet access enabled during the agent phase (per docs).
-
I’ve read that Codex Cloud environments egress via an HTTP/HTTPS proxy for security and abuse prevention, and internet access is configurable. I suspect the proxy blocks outbound SSH (22) and possibly WebSockets.
Expectation
Be able to run TCC in Codex Cloud (agent phase) similar to local runs. TCC needs outbound connectivity to worker endpoints (SSH 22 or WebSocket 443/80) after a lease is obtained.
Questions for the Codex team
-
Is outbound SSH (22) from Codex Cloud agents blocked even with “Full” internet access? If so, is WebSocket egress (443/80) permitted end‑to‑end without proxy termination that prevents the TCC handshake?
-
Is there an allow‑list path (e.g.,
*.testcontainers.cloud) we can configure in the environment so the agent can reach workers? -
Any recommended pattern to make Testcontainers Cloud work inside Codex Cloud, or should we stick to local Codex runs for TCC‑backed integration tests?