Codex CLI timeout because of sandboxed environment

[archneon]

Hello,

my system: Ubuntu 22.04

there seems to be a problem with running python tests. Codex CLI agent says it's probably because of the sandboxed environment.

MY QUESTION/TASK FOR CODEX CLI:

Hmmm, I'm not sure why did pytest timeout when you ran the command? I've ran it manually myself in my terminal and it was successful for both test commands, take a look:

ubuntu@i9:~/archProjects/imagetools$ poetry run pytest tests/backend ============================================== test session starts =============================================== platform linux -- Python 3.11.2, pytest-8.4.1, pluggy-1.6.0 rootdir: /home/ubuntu/archProjects/imagetools configfile: pytest.ini plugins: asyncio-1.2.0, anyio-4.9.0 asyncio: mode=Mode.STRICT, debug=False, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function collected 81 items

tests/backend/generate/test_combined_api.py ............. [ 16%] tests/backend/generate/test_corners_api.py .............. [ 33%] tests/backend/generate/test_sam_api.py ............... [ 51%] tests/backend/images/test_images_api.py ............... [ 70%] tests/backend/projects/test_projects_api.py .................. [ 92%] tests/backend/test_health_api.py ... [ 96%] tests/backend/test_settings_api.py ... [100%]

=============================================== 81 passed in 0.40s =============================================== ubuntu@i9:~/archProjects/imagetools$ poetry run pytest -q ......................................................................................................... [100%] 105 passed in 0.83s ubuntu@i9:~/archProjects/imagetools$

I assume it the timeout occured because of the sandboxed environemnt Codex CLI is using? Could you please retry running both commands again?

CODEX CLI REPLY:

I’ll retry running the test suite as you did, starting with backend tests, then full tests if it works.

• Ran poetry run pytest tests/backend -q └ error: command timed out

• Ran poetry run pytest -q └ error: command timed out

Understanding

• Goal: Re-run pytest like you did to confirm everything passes.
• Assumptions: Your local run shows tests are green; my earlier timeout is due to the CLI sandbox limits.
• Ambiguities: None; action is just to retry under our constraints.

Update

• I retried poetry run pytest tests/backend -q and poetry run pytest -q here. Both timed out again in this sandbox.
• Your local results confirm the suite is healthy: 81 backend tests and 105 total passing in under a second.

Completion

• Outcome: Verified that timeouts are sandbox-related on my side; your local environment runs pass, so changes are compatible with the test suite. No further code changes were needed.
• Files: None
• Validation:
  • $ poetry run pytest tests/backend -q → exit_code=124 — command timed out…
  • $ poetry run pytest -q → exit_code=124 — command timed out…
• Notes:
  • The Codex CLI sandbox sometimes restricts long-running or multi-process test execution, causing timeouts even when tests are correct.
  • We already validated Python imports with poetry run check-python, and frontend type-check and lint both passed earlier.

As you can see the commands timeout! In Claude code this works fine. Could you guys fix this problem, because this is pretty limiting!

kind regards, Arch

[zuuxuux]

Is it a specific test in particular that is timing out? You could ask Codex to run subsets of the tests to try and locate the offending test

[ryan-hallman]

Confirmed on my end, it can't run pytest -q. Downgrading back to 0.31.0 fixes the issue

[rodolfovilaca]

I'm also getting the same issue. My tests run fine on terminal, but codex simply cannot run it. I also tried running codex in sandbox write mode.

Also downgraded to get it back working.

[ryan-hallman]

This issue turned out to be most likely not codex related but an issue related to one of our packages redirecting $XDG_DATA_HOME. A brief explanation:

What your strace shows:

• Repeated mkdir("~/.local/share/{project_dir_name}/logs", …) = -1 EEXIST (so it already exists).
• Thousands of newfstatat checks over the same paths.
• Crucially, repeated ENOENT on ~/.local/share/{project_dir_name}/registry/settings.json.

There are no meaningful openat/read/I/O calls, no sleeps, no polling syscalls — just metadata checks. That’s classic “spin until a file appears.” Likely a regression in 0.36.0 during startup/plugin discovery where a default config isn’t created and a loop keeps checking for settings.json.

Quick unstick options (pick one)

1. Create the missing file (fastest)

mkdir -p ~/.local/share/{project_dir_name}/registry
printf '{}\n' > ~/.local/share/{project_dir_name}/registry/settings.json
pytest -q

[archneon]

Hi @ryan-hallman

I followed your suggestion ,your work-around idea, but it did not work.

I installed latest version first.
~/archProjects/imagetools$ codex --version
codex-cli 0.39.0

Then i followed your instructions:
archneon@i9:~/.local/share/imagetools/registry$ pwd
/home/archneon/.local/share/imagetools/registry
archneon@i9:~/.local/share/imagetools/registry$ ls
settings.json
archneon@i9:~/.local/share/imagetools/registry$ cat settings.json 
{}

...but it is exactly the same. When Codex CLI tries to run: poetry run pytest tests/backend ... it still timeouts in 120 seconds. It does nothing.

When i run tests manually in my Kubuntu terminal it finishes in 0.47s, so it's very quick:

~/archProjects/imagetools$ poetry run pytest tests/backend
============================================== test session starts ===============================================
platform linux -- Python 3.11.2, pytest-8.4.1, pluggy-1.6.0
rootdir: /home/dino/archProjects/imagetools
configfile: pytest.ini
plugins: asyncio-1.2.0, anyio-4.9.0
asyncio: mode=Mode.STRICT, debug=False, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function
collected 100 items                                                                                              

tests/backend/generate/test_combined_api.py .....................                                          [ 21%]
tests/backend/generate/test_corners_api.py .........................                                       [ 46%]
tests/backend/generate/test_sam_api.py ...............                                                     [ 61%]
tests/backend/images/test_images_api.py ...............                                                    [ 76%]
tests/backend/projects/test_projects_api.py ..................                                             [ 94%]
tests/backend/test_health_api.py ...                                                                       [ 97%]
tests/backend/test_settings_api.py ...                                                                     [100%]

============================================== 100 passed in 0.47s ===============================================

In Claude Code this problem does not exist! Guys, please fix this issue, because It is extremely difficult to work around it. Basically whatever Codex agent CLI fixes/changes, it cannot executes tests at the end, which means, its is basically just guessing if his refactor was a success!

Pleeeease fix this BUG <3

Best regards, Arch

[TobiasAlexanderWulff]

I got the same issue..

[SOCSChamp]

Seconded. This is a nightmare and EVERY SESSION involves sandbox timeouts for basic commands, which it then burns through tokens troubleshooting irrelevant timeout issues on the project itself. The dangerously bypass approvals flag still runs into this issue, which is absurd.

[tamasarpad]

This is an issue with dotnet commands as well. This worked well for me so far:

**IMPORTANT**: anytime you run into sandbox permission issues, timeouts, let me know.
DO NOT try to find workarounds. Try to run EVERY dotnet command with elevated permissions.
Without that, they can fail (timeout, failure to access network, etc)

Similar issue: https://github.com/openai/codex/issues/3269

[neleid]

Same here. Codex couldn't run PestPHP on terminal. MacOS. Pest is built on top of PHPUnit, Probably codex cannot run PHPUnit too. Claude Code can run tests with no problem.

[edoardo-bluframe]

Hey everybody! Same here! Our E2E tests take long - is that a surprise?? - and Codex often times out then says "retrying with longer timeout". And then it works

So... can we just get a config parameter to set that longer timeout by default? Since it is able to change itself? 😄

[mimoo]

+1 here, I ask it to run with 30min timeout by default and the command still fail (in spite of completing, it still returns exit code 124)

[sosarya]

same here this is nonsense

[mimoo]

what I ended up doing is prefixing any prompt with "ignore exit code 124, assume the command successfuly worked"

[sayan-oai]

Hey @archneon, can you share the thread-id of a session if you're still seeing this issue? You can get the thread-id via the /feedback command in the CLI. Thanks

[mimoo]

I ended up changing technique, realizing that the agent can do it by himself in the MCP argument, so I added this to my prompt:

commands you run have a short default timeout of 10s. Since "agent-runner" tasks tend to take time, call the command tool involving an agent-runner command with a timeout_ms argument set to 1800000 (30 minutes).