[Linux] Interactive Codex TUI freezes entire desktop; `codex exec` works normally (0.146.1 and 0.147.0)

Open 💬 3 comments Opened Aug 8, 2026 by StarkLeeSunny
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

  1. codex --no-alt-screen
  2. Fresh CODEX_HOME with only valid auth.json
  3. CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1
  4. Disabling most authenticated stable UI/tool features, including:
  • apps
  • browser_use
  • browser_use_external
  • browser_use_full_cdp_access
  • computer_use
  • in_app_browser
  • plugins
  • plugin_sharing
  • remote_plugin
  • tool_suggest
  • hooks
  • memories
  • goals
  1. Minimal TUI config with rendering features disabled:
[tui]
animations = false
terminal_title = []
notifications = false
show_tooltips = false
alternate_screen = "never"
status_line = []
  1. GNOME Terminal
  2. xterm
  3. Codex CLI 0.147.0
  4. Codex CLI 0.146.1 via temporary npx test

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)

  1. Have a valid ChatGPT login for Codex.
  2. 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/
  1. Launch interactive Codex:
CODEX_HOME=/tmp/codex-repro codex
  1. Observe the interactive TUI/desktop freeze.
  1. 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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 20 days ago

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

  • #37544

Powered by Codex Action

StarkLeeSunny · 20 days ago

Update after the original report: a complete clean reinstall resolved the problem.

Procedure used:

  1. Moved the entire existing ~/.codex aside as a backup rather than deleting it.
  2. Removed the old standalone launcher at ~/.local/bin/codex.
  3. Confirmed no global npm @openai/codex installation remained.
  4. Reinstalled Codex standalone from scratch, creating a fresh ~/.codex.
  5. Logged in again with ChatGPT.
  6. Launched interactive codex before 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 ~/.codex state rather than Ubuntu, the ChatGPT account, network/WebSocket connectivity, the standalone binary alone, or GNOME Terminal/xterm. The earlier clean-CODEX_HOME experiments 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 ~/.codex tree 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.

boombx403-byte · 9 days ago

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:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest --json

(or point doctor directly to the rollout file). Please sanitize/redact any sensitive paths or names before sharing diagnostic output; raw session files are never needed.