Most of shell tools are timing out

Resolved 💬 6 comments Opened Sep 17, 2025 by leobuskin Closed Nov 11, 2025

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.36.0

Which model were you using?

any

What platform is your computer?

Linux 6.12.10-76061203-generic x86_64 x86_64

What steps can reproduce the bug?

Whenever the model decides to run a shell tool it hangs for a while, ends up with a red dot next to it, and the model sees the timeout. Any shell command (90% cases) fail this way, which is highly frustrating. I came to Codex from Claude Code, and had never experienced such issues.

What is the expected behavior?

To have at least some visibility in what happened with the shell command.

What do you see instead?

Red dot and model knows about timeout.

Additional information

_No response_

View original on GitHub ↗

6 Comments

vuyelwadr · 11 months ago

same. literally see this when i simply start up the tool
■ MCP client for playwright failed to start: request timed out

■ MCP client for zen failed to start: request timed out

as we speak its trying to read a readme.md which last week it easily did but now it starts reading it then times out then starts to investigating itself timing out. strange, i literally just installed the latest version. will try to build from source and see if that helps.

om on mac

vuyelwadr · 11 months ago

my problem is almost certainly due to high cpu usage. this issue started last night and it fluctuates. i've been running a cpu heavy script since last night so codex tries to do something but cant since cpu is mostly occupied.
script will probably finish this time tomorrow or the day after so ill update then. (and don't ask what it is thats running i know 3 days is a lot :)

vuyelwadr · 11 months ago

confirmed for me it was my high cpu usage. Works perfectly now

mion-kr · 11 months ago

same issue

leobuskin · 11 months ago

> The timeouts aren’t coming from the CLI—they’re caused by your shell init. Every shell call starts a login shell (bash -lc …), which runs eval "$(pyenv init --path)" from ~/.profile:18.
  That snippet ends with command pyenv rehash 2>/dev/null, so every command we run first executes pyenv rehash.

  Inside this CLI we’re still sandboxed from writing to ~/.pyenv/shims, so pyenv-rehash can’t create its .pyenv-shim lock file. With PYENV_DEBUG=1 pyenv rehash you can see it looping in
  acquire_lock (~/.pyenv/libexec/pyenv-rehash:33-58) until our 60 s command budget expires. That’s why you saw the pyenv: cannot rehash: … message followed by a timeout.

  Evidence:

  - PYENV_DEBUG=1 pyenv rehash → endless acquire_lock loop until the CLI kills it (no other output before timeout).
  - touch ~/.pyenv/shims/codex_test → Permission denied, confirming the sandbox blocks writes there even though the directory’s mode bits look writable.
  - Running commands with a clean shell (/bin/bash --noprofile --norc -lc "command -V ls") avoids the rehash call and succeeds instantly.

  Workarounds:

  1. Inside this session I can switch to ["/bin/bash","--noprofile","--norc","-lc", …] to skip your login scripts when we need trouble-free commands. Let me know if that’s acceptable.
  2. On your side you could guard the pyenv init --path block (e.g., check for an env flag before running it), or point PYENV_ROOT to a path inside the writable workspace so rehash can
  create its shims, or remove the rehash call entirely for this environment.

GPT tried to analyze the problem with timeouts. I'm not sure what we're dealing with here exactly. Just in case, Claude Code works with no issues related to pyenv (yes, I have it installed)

etraut-openai contributor · 9 months ago

I think this issue is no longer relevant, so I'm closing. If you are seeing similar problems with the latest versions of codex, please file a new issue with details.