FastAPI TestClient pytest commands time out under Codex CLI when network access is restricted

Resolved 💬 2 comments Opened Oct 22, 2025 by jrmlhermitte Closed Oct 23, 2025
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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!

example-fastapi-timeout.zip

<details>
<summary>High level user journey</summary>
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.
</details>

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
```bash
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                                                                                                         
  ```bash                                                                                                                         
  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_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 10 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #4279
  • #4773
  • #3557
  • #3692
  • #4434

Powered by Codex Action

jrmlhermitte · 10 months ago

The first issue #4279 is similar. See this comment here

Adding this to $HOME/.codex/config.toml:

[sandbox_workspace_write]
network_access = true

addressed the issue.

Note I previously tried adding a warning to my custom AGENTS.md of the form:

- **Sandbox note:** CLI commands run in a network-isolated sandbox by default.
  Loopback sockets are blocked, so HTTP clients may hang or time out unless you
  escalate the command for network access. Assume tests that spin up web
  clients need approval.

After having the agent run the same tests and letting it troubleshoot with this AGENTS.md change, about 20 min it was still going down some deep rabbit holes. I ended up canceling it and making the config.toml change for now. I don't know what else to suggest but that this network issue be more documented and the agent reminded it can be an issue. So the suggestion from Codex I got:

Allow loopback socket usage even when network_access is restricted, or document that FastAPI/Starlette TestClient requires elevated network permissions inside Codex CLI.

seems like the right thing.

I'll dedupe and add a comment there.