Codex CLI timeout because of sandboxed environment

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

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

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.

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

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

I got the same issue..

<img width="516" height="134" alt="Image" src="https://github.com/user-attachments/assets/88078d90-0ea5-4428-bb27-e8a89ca08a6d" />

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.

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

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.

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? 😄

+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)

same here this is nonsense

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

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

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).

I'm suffering this even in agent mode. What's the workaround?

FYI this totally works now for us as of 0.114.0!! 🎉