[Linux] Interactive Codex TUI freezes entire desktop; `codex exec` works normally (0.146.1 and 0.147.0)
Summary
On Linux, launching the interactive Codex TUI causes the entire desktop session to become effectively frozen/unusable. This is reproducible locally (not only over remote desktop), across both GNOME Terminal and xterm, and on both Codex CLI 0.146.1 and 0.147.0.
In contrast, non-interactive codex exec works normally with the same ChatGPT authentication, provider, network, and model. codex doctor --summary reports a healthy installation, authentication, state DBs, threads, WebSocket connection, and provider reachability.
The failure appears specific to the authenticated interactive TUI/TTY path.
Environment
- Platform: Linux x86_64 / Ubuntu desktop
- Codex installation: standalone
- Primary affected version:
codex-cli 0.147.0 - Also reproduced on:
@openai/codex@0.146.1 - Terminal emulators tested:
- GNOME Terminal
- xterm
- Authentication: ChatGPT
- Model used successfully via
codex exec:gpt-5.6-sol - Remote desktop was initially in use (AnyDesk), but the exact same freeze reproduces while physically at the machine with AnyDesk not in use, so AnyDesk is ruled out.
User-visible symptom
Running interactive:
codex
may initially draw/open the TUI, but then the desktop becomes effectively frozen. In some tests the freeze occurs immediately on launch. GUI menus may still partially draw/respond at first, but applications do not react and terminal input becomes unusable. In xterm the freeze can occur essentially as soon as the codex command is entered.
Because the freeze affects desktop interaction, repeated interactive reproduction is disruptive and requires recovery/restart.
Important control: non-interactive mode works
The following succeeds normally:
cd /tmp
timeout -k 2s 20s codex exec \
--ephemeral \
--ignore-user-config \
--ignore-rules \
--skip-git-repo-check \
"Reply with exactly OK"
Observed output:
OpenAI Codex v0.147.0
--------
workdir: /tmp
model: gpt-5.6-sol
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: 019fdfec-8391-7962-8872-16e14a07db57
--------
user
Reply with exactly OK
warning: Skill descriptions were shortened to fit the skills context budget. Codex can still see every skill, but some descriptions are shorter. Disable unused skills or plugins to leave more room for the rest.
codex
OK
tokens used
7,858
EXEC_EXIT=0
This shows authentication, network/provider access, model invocation, and the core agent path are functional.
Authentication isolation
A fresh CODEX_HOME without existing authentication can reach the login UI normally.
However, copying only the existing auth.json into an otherwise fresh CODEX_HOME causes authenticated interactive startup to hang until killed by timeout:
rm -rf /tmp/codex-probe
mkdir -p /tmp/codex-probe
cp ~/.codex/auth.json /tmp/codex-probe/
timeout -k 2s 15s env CODEX_HOME=/tmp/codex-probe codex
Result:
EXIT=124
The old auth file was then safely moved aside and Codex was launched unauthenticated. The login UI appeared normally. After a fresh ChatGPT login was completed, interactive Codex again froze. Therefore this is not simply a corrupted/stale auth.json.
Credential read itself works normally:
timeout -k 1s 5s codex login status
Output:
Logged in using ChatGPT
STATUS_EXIT=0
codex doctor --summary
Codex Doctor v0.147.0 · linux-x86_64
Notes
⚠ rollouts 811 active files · 2.67 GB on disk
─────────────────────────────────────────────────────────────
Environment
✓ system en-US
✓ runtime standalone (unix, package /home/chris/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl, bin /home/chris/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin, resources /home/chris/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-resources, path /home/chris/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path)
✓ install consistent
✓ search file exists (bundled, /home/chris/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path/rg)
✓ git git version 2.43.0
✓ terminal GNOME Terminal
✓ title default · project chris
✓ state databases healthy
✓ threads rollout files and state DB thread inventory agree
Configuration
✓ config loaded
✓ auth auth is configured
✓ mcp 1 server (1 stdio) · 0 disabled
✓ sandbox restricted fs + restricted network · approval OnRequest
Updates
✓ updates update configuration is locally consistent
Connectivity
✓ network no proxy env vars
✓ websocket connected (HTTP 101 Switching Protocols) · 15s timeout
✓ reachability active provider endpoints are reachable over HTTP
Background Server
○ app-server not running (ephemeral mode)
─────────────────────────────────────────────────────────────
17 ok · 1 idle · 1 notes · 0 warn · 0 fail ok
The rollout-size note does not appear causal because the issue also reproduces with a fresh CODEX_HOME containing only authentication.
Installation state
type -a codex
which -a codex
npm list -g @openai/codex --depth=0
npm config get prefix
Output:
codex is /home/chris/.local/bin/codex
codex is /home/chris/.local/bin/codex
/home/chris/.local/bin/codex
/home/chris/.local/bin/codex
/home/chris/.nvm/versions/node/v24.14.1/lib
└── (empty)
/home/chris/.nvm/versions/node/v24.14.1
Resolved binary:
/home/chris/.local/bin/codex -> /home/chris/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex
So the active installation is standalone; no global npm Codex package is installed. The duplicate type -a entry is the same path appearing twice, not two different Codex binaries.
Additional isolation tests already performed
All of the following still reproduced the interactive freeze:
codex --no-alt-screen- Fresh
CODEX_HOMEwith only validauth.json CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1- Disabling most authenticated stable UI/tool features, including:
appsbrowser_usebrowser_use_externalbrowser_use_full_cdp_accesscomputer_usein_app_browserpluginsplugin_sharingremote_plugintool_suggesthooksmemoriesgoals
- Minimal TUI config with rendering features disabled:
[tui]
animations = false
terminal_title = []
notifications = false
show_tooltips = false
alternate_screen = "never"
status_line = []
- GNOME Terminal
- xterm
- Codex CLI 0.147.0
- Codex CLI 0.146.1 via temporary
npxtest
The freeze therefore does not appear to be caused solely by alternate-screen mode, keyboard enhancement, animations/window-title updates, the user's existing plugins/sessions/config, GNOME Terminal specifically, or a regression unique to 0.147.0.
Feature state
codex features list shows stable features including apps, auth_elicitation, browser/computer-use features, goals, hooks, memories, plugins, remote_plugin, shell_snapshot, tool_suggest, and unified_exec; under-development features are mostly disabled. A broad disable test did not prevent the freeze.
Expected behavior
Interactive codex should open a responsive TUI without making the Linux desktop/terminal session unusable.
Actual behavior
Authenticated interactive TUI startup freezes terminal/desktop interaction. Non-interactive codex exec remains fully functional.
Reproduction (minimal known case)
- Have a valid ChatGPT login for Codex.
- Create a clean Codex home containing only the valid auth file:
rm -rf /tmp/codex-repro
mkdir -p /tmp/codex-repro
cp ~/.codex/auth.json /tmp/codex-repro/
- Launch interactive Codex:
CODEX_HOME=/tmp/codex-repro codex
- Observe the interactive TUI/desktop freeze.
- Compare with:
CODEX_HOME=/tmp/codex-repro codex exec --ephemeral --ignore-user-config --ignore-rules --skip-git-repo-check "Reply with exactly OK"
which succeeds.
Notes for maintainers
Because interactive reproduction can freeze the user's local desktop input, further reproduction is disruptive. If there is a preferred non-interactive tracing method (e.g. specific RUST_LOG targets, strace flags, terminal event tracing, or a diagnostic build) that does not require repeatedly entering the live TUI, instructions would be appreciated.
The user plans to perform a complete Codex reinstall after preserving local Codex data, so the pre-reinstall state is documented here first.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Update after the original report: a complete clean reinstall resolved the problem.
Procedure used:
~/.codexaside as a backup rather than deleting it.~/.local/bin/codex.@openai/codexinstallation remained.~/.codex.codexbefore restoring any old config, sessions, plugins, SQLite state, cache, or other files.Result: interactive Codex now works normally and no longer freezes the desktop.
This strongly suggests the trigger was somewhere in the previous local
~/.codexstate rather than Ubuntu, the ChatGPT account, network/WebSocket connectivity, the standalone binary alone, or GNOME Terminal/xterm. The earlier clean-CODEX_HOMEexperiments narrowed the issue but did not reproduce the fully clean reinstall state exactly because authentication/local state was being selectively copied back in during diagnosis.The old
~/.codextree is still preserved, so individual components can be restored incrementally if maintainers want help isolating the exact offending state (e.g. config, plugins, sessions, or specific state files) without restoring the entire directory at once.Hi @StarkLeeSunny, the frozen history/resume behavior you described is one of the persistence patterns I've been studying. Codex Rescue Alpha5 includes a read-only projection consistency check that compares canonical rollout progress against stored projection cursors without touching SQLite.
If you still have the affected pre-repair session locally, you can test it with:
(or point
doctordirectly to the rollout file). Please sanitize/redact any sensitive paths or names before sharing diagnostic output; raw session files are never needed.