FastAPI TestClient pytest commands time out under Codex CLI when network access is restricted #5533
Description
What version of Codex is running?
codex-cli 0.47.0
What subscription do you have?
Plus
Which model were you using?
gpt-5-codex
What platform is your computer?
Linux
What issue are you seeing?
High Level Description
I'll write a high level description to describe my user journey, and then follow it with the concrete problem. I would consider the issue solved if the concrete problem is addressed, but do want to highlight this potentially problematic user journey.
Anyway, issues are designed to be negative (point out problems) so before I continue, just want to say, keep up the great work!
High level user journey
It looks like codex will try to run commands without network access by default. This is great but in my case has led my developer getting stuck in a confusing loop. We were running a python test with `pytest` and it was failing because the FastAPI test client breaks in this hermetic sandbox. However, when asked, the agent had no clue this was happening.I only figured this out by drilling it with questions and having it create a new test package and noticed when it did so, it was failing to install packages. When I asked it, it finally revealed to me that commands are run in a network isolated sandbox that can be bypassed if I ask it to try connecting to the network. I then asked it to run the same tests but ask me permission to connect to the web and it succeeded.
I think what might address this is to possibly make the model more aware of this. I can easily address this by updating my AGENTS.md but I worry this might affect others in an unpleasant way.
Agent's Description
(Description recommended by agent)
Environment
- Codex CLI (GPT-5 / Codex agent)
network_access = restricted(sandbox blocks outbound + loopback sockets)- Python 3.12.3 via Poetry-managed virtualenv
Minimal Reproduction
poetry init --no-interaction --name example --python "^3.11"
poetry add fastapi
poetry add --group dev pytest
Create tests/test_fastapi_client.py:
from fastapi import FastAPI
from fastapi.testclient import TestClient
app = FastAPI()
@app.get("/ping")
def ping():
return {"status": "ok"}
def test_fastapi_client_request():
client = TestClient(app)
response = client.get("/ping")
assert response.status_code == 200
assert response.json() == {"status": "ok"}Run:
poetry run pytest tests/test_fastapi_client.py -vv
Observed Behavior
Pytest hangs indefinitely; Codex CLI aborts the command after 120 s with command timed out after 120000 ms.
Expected Behavior
The test should complete immediately (< 1 s) as it does when run locally outside Codex.
Additional Notes
- Non-FastAPI tests (e.g., tests/test_sample.py) run fine under the same conditions.
- Granting network access (via CLI approval) allows the FastAPI test to pass instantly.
- In a separate project (Squirrel worker), only tests that use TestClient exhibit the timeout; everything else passes without
network access.
Likely Cause
FastAPI’s TestClient relies on httpx opening loopback sockets to communicate with the ASGI app. The Codex sandbox treats those
sockets as “network access” and blocks them, so the request never completes.
Suggested Fix
Allow loopback socket usage even when network_access is restricted, or document that FastAPI/Starlette TestClient requires
elevated network permissions inside Codex CLI.
Repro attachment
example-fastapi-timeout.zip (created in the session) contains the minimal project.
What steps can reproduce the bug?
Minimal Reproduction
poetry init --no-interaction --name example --python "^3.11"
poetry add fastapi
poetry add --group dev pytest
Create tests/test_fastapi_client.py:
from fastapi import FastAPI
from fastapi.testclient import TestClient
app = FastAPI()
@app.get("/ping")
def ping():
return {"status": "ok"}
def test_fastapi_client_request():
client = TestClient(app)
response = client.get("/ping")
assert response.status_code == 200
assert response.json() == {"status": "ok"}Run:
poetry run pytest tests/test_fastapi_client.py -vv
What is the expected behavior?
The test should complete immediately (< 1 s) as it does when run locally outside Codex.
Additional information
No response