[codex-cli error after upgrading to 0.121.0] Error: thread/start failed during TUI bootstrap

Resolved 💬 7 comments Opened Apr 16, 2026 by fengxin-zhxx Closed Apr 16, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.121.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4

What platform is your computer?

linux x64

What terminal emulator and version are you using (if applicable)?

VSCode

What issue are you seeing?

Everything works correctly with version 0.118.0.
After upgrading to 0.121.0, running codex in the terminal fails with the following error:
Error: thread/start failed during TUI bootstrap

What steps can reproduce the bug?

npm install -g @openai/codex@0.121.0
codex

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 3 months ago

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

#17593

Powered by Codex Action

etraut-openai contributor · 3 months ago

I'd normally ask you to use /feedback to upload your logs, but if it crashes at launch, that's not possible. You can look at the logs yourself, and it might give you a clue as the cause of the crash. Look at the contents of ~/.codex/log/codex-tui.log. It's possible that there's some corrupt state in the ~/.codex directory. You could try temporarily renaming it and see if you can launch without crashing.

fengxin-zhxx · 3 months ago

I investigated this with Codex and found the root cause.

In 0.121.0, Codex calls flock() on ~/.codex/installation_id during TUI bootstrap. In my environment, ~/.codex is stored on a mounted workspace path rather than a local disk path, and that storage does not support flock(), so it returns ENOSYS and causes Error: thread/start failed during TUI bootstrap.

I verified that 0.121.0 works again if I either move ~/.codex to a local filesystem, or keep ~/.codex where it is but make installation_id a symlink to a file on a local filesystem.

georgi · 3 months ago

still see this issue from 120.0 onwards, ~/.codex/installation_id is local for me

sator-imaging · 3 months ago

In my case, I do mount the .codex folder in WSL environment to make environment consistent with Codex App.

kMutagene · 3 months ago

same problem here in a dev container

madnight · 3 months ago

In my case I was able to fix it by chown recursive of the .codex folder