Codex commands timeout issue

[LaurentEsingle]

What version of Codex is running?

codex-cli 0.63.0

What subscription do you have?

"Plus"

Which model were you using?

gpt-5.1-codex

What platform is your computer?

Linux 6.8.0-1040-aws x86_64 x86_64

What issue are you seeing?

Her is an snippet of its thinking:

I'm puzzling over why every command times out, suspecting that shell initialization scripts like .bashrc might be hanging the shell by waiting for input or running indefinitely.
  Since the harness likely runs commands via bash -lc, it may source those scripts and cause blocks. I'm considering ways to bypass this, like using env -i with bash --noprofile
  --norc or setting BASH_ENV=/dev/null to avoid sourcing, but the first-level shell invocation might still trigger them. Other leads include possible issues with working directory
  access, network mounts delaying cd, or environment hooks like pyenv or direnv interfering. Given the repeated 124 timeout status, I’m leaning toward needing to inform the user
  commands can't run here or to escalate permissions, but I want to perform more diagnostics, maybe extend timeout to 120 seconds or trace command execution to gather clues before
  concluding

It ends up saying something like:

Tried multiple simple commands (ls, pwd, cat instructions.md, even a tiny Python print) inside <path to my project>, but every attempt timed out—no output at all—so
  I couldn’t read instructions.md. Looks like the workspace is currently unresponsive to shell commands. Could you check whether the directory is accessible on your end or share the
  file contents another way?

What steps can reproduce the bug?

Uploaded thread: 019ac6a8-905d-76e0-b03b-f0e4502f0788

What is the expected behavior?

codex should be able to run simple unix commands like ls

Additional information

I have to specifically instruct it as follows in every prompt: "Please escalate your commands or you will face hang issues due to sandbox"

Then everything works immediately.

[github-actions[bot]]

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

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

Powered by Codex Action

[vlasky]

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.

[brainopener]

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

[DavyMassoneto]

Same here, in Ubuntu 24.04

[vlasky]

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.

[vlasky]

I see this issue is not new:

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

[vlasky]

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

[IceKickr]

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

[aosama]

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)

[smith558]

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