Codex commands timeout issue

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

• #7084
• #7006
• #6374
• #6090

Powered by Codex Action

I am experiencing this exact same problem with the exact same codex version in WSL2 (Ubuntu 24.04) under Windows 10.

It can't even run 'ls' or read CLAUDE.md. The shell commands time out with exit code 124. The problem goes away when I run codex with --yolo.

Same "124" exit code issue that resolves if I run codex with --yolo. This is Debian 13 (6.12.57+deb13-amd64).

Same here, in Ubuntu 24.04

I've made progress diagnosing the problem. It happens when I have the following lines in my .profile file:

export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

When you launch codex with the sandbox enabled, pyenv produces the following error:

pyenv: cannot rehash: /home/vlasky/.pyenv/shims/.pyenv-shim exists

I asked codex to debug itself and it said:

The .profile initializes pyenv on each shell start (setting environment and running pyenv init), which triggers pyenv to try rehashing. The rehash fails with exit code 2 due to a leftover file (.pyenv-shim) in /.pyenv/shims, causing the warning every time a new shell session starts. Removing this stray file or reinstalling pyenv will resolve the issue.

This problem does not happen under claude or gemini so I am certain it is specific to codex's sandbox. This should give a big clue to codex's maintainers.

Commenting out the pyenv lines gets it working, but obviously this is not a solution.

I see this issue is not new:

• https://github.com/openai/codex/issues/3891

This issue has been fixed in pyenv 2.6.16:

https://github.com/pyenv/pyenv/releases/tag/v2.6.16

Easiest way to update pyenv to the latest version is to run the following command from your terminal window:

pyenv update

For more information on the cause and resolution of the issue, see:

• https://github.com/pyenv/pyenv/issues/3365
• https://github.com/pyenv/pyenv/pull/3367

Confirmed that these entries in my .bashrc were causing the timeout:


if command -v pyenv 1>/dev/null 2>&1; then
eval "$(pyenv init -)"
fi


experiencing command timeout as well ... please read thread ID 019af6db-13ac-7340-9cf4-c7699df0e62f

I reproduced the issue on macOS but it wasn’t pyenv-related in my case. The default Codex shell tool kills commands after ~10s
unless I explicitly set a higher timeout_ms on the tool call. Once I pass timeout_ms (e.g., 180000), mvn clean install completes.
On this machine there’s no pyenv in shell init, so the root cause appears to be the tool’s built-in timeout rather than pyenv.
Suggest exposing/documenting the default timeout or allowing a user-level override to avoid confusion.
running CLI 0.65.0

>_ OpenAI Codex (v0.65.0)
Sandbox: danger-full-access
Model: gpt-5.1-codex-max (reasoning xhigh, summaries auto)

If you have pyenv installed. The latest version, 2.6.16, includes a compatibility fix to work with Codex's sandbox mode. Update it to the latest version using pyenv update. See the following issue for more information:

https://github.com/openai/codex/issues/7353#issuecomment-3619122843

I asked codex what to do about this 😛

This actually fixed it though. Skip your fancy shell settings top of your .profile or ~/.bashrc (wherever your asdf/pyenv/fancy-shell goes)
[[ $- != *i* ]] && return

Thank you @smith558
I confirm it works well once pyenv is updated.

Reopening the issue.
It was working fine when I updated pyenv.
Later on, I was prompted to update codex (went from 0.64.0 v0.77.0). As soon as I did, the following warnings started popping up
They do not prevent codex from completing the work but it's annoying.

Explored
  └ List ls

• I see pyenv warns about rehash errors and suggests rerunning commands with a bash wrapper to avoid hangs; since commands succeed but with warnings, I plan to adopt
  this wrapper pattern for stability. Meanwhile, I’m preparing to add a deletion route to the FastAPI app by first locating existing routes using ripgrep, so I can
• Ran bash --noprofile --norc -c "rg -n \"get_signals\" -n"
  └ mktemp: failed to create file via template ‘/home/tfruser/.pyenv/shims/tmp.XXXXXXXXXX’: Permission denied
    pyenv: cannot rehash: /home/wsluser/.pyenv/shims isn't writable
    … +11 lines

I had to put "Use a default timeout of 300 seconds for commands." in the ~/.codex/AGENTS.md file. That seems to solve the issue.

This results in codex calling any commands with a timeout 300s wrapper.

The downside of this is that it screws up execpolicy prefixes.

I asked the agent about this:

› Does your command execution harness give you an explicit timeout option?


• No — the harness doesn’t expose an explicit timeout parameter. I use timeout 300 ... in the shell
  instead, and the tool only supports yield_time_ms for how long to wait before returning output.


› No `timeout_ms`?


• Correct — there’s no timeout_ms option. Only yield_time_ms is available, so I use the shell timeout
  command when needed.

Again, I don't understand why the agent isn't given explicit control over its own timeouts. It's a massive pain point for any kind of serious work.

[[ $- != *i* ]] && return

the thing is still VERY slow but it's not timing out just trying to use basic tools.

Looks like the new version of Codex has a workaround? Now it identifies the issue at the start then uses other approaches to access the files:

``The command showed a pyenv error but confirmed file presence with ls; now I'll read the file contents using sed or ripgrep for clearer insight.
Read dashboard.md``

After this initial notice, I get no complaints during the rest of the execution. Or maybe it is not related.

Looks like the new version of Codex has a workaround? Now it identifies the issue at the start then uses other approaches to access the files: `` Read dashboard.md` After this initial notice, I get no complaints during the rest of the execution. Or maybe it is not related. ``

Nope, still facing the same issue.

This issue looks closure-ready if the current environment no longer reproduces it.

The failure boundary is:

command requested in sandbox
≠
shell initialization path is guaranteed to terminate

The report indicates that simple commands such as ls, pwd, and cat timed out, while explicitly escalating commands made them work immediately.

That suggests the root problem is not the command payload itself, but the execution environment selected for sandboxed shell startup.

Minimal closure check:

1. retest with the latest Codex CLI;
2. run a simple command without escalation:

pwd

1. run the same command with the previously required escalation path;
2. if both now return, this issue can be closed as fixed by the current runtime/environment;
3. if only escalation works, the issue should remain open but be relabeled as sandbox shell-startup compatibility, not generic command timeout.

Closure boundary:

sandboxed shell startup must produce a terminal outcome for simple commands, or Codex should fail locally with a named diagnostic explaining the unsupported startup layer.

I'm no longer facing this issue with codex. Would love to know the 'yolo' mode of codex tho :)