linux desktop app 26.924 hangs on opening any local Codex thread — hydration never sends thread/resume, 120s timeout

Env: Fedora 44 (KDE, x64), kernel 7.2.7. App: ChatGPT for Linux preview, RPM chatgpt-26.924.22138-1 (buildNumber 11645, commit 2e782921) — also reproduced on 26.924.20706-1 (buildNumber 11431, commit 97cf4a3c). Bundled app-server: codex-cli 0.158.0-alpha.2.1. CLI installed separately: 0.157.1 (healthy).

Regression: worked on 26.917.71314 (43/43 thread_hydration outcome=success, ~1.8 s, thread/resume 825 ms). After updating to 26.924: opening any local thread spins forever.

Evidence (journalctl --user):

thread_hydration outcome=failure reason=timeout durationMs=120000.3 marksMs={"writable_roots_ready":28.7,"metadata_ready":45.1} (9× on 20706, 1× on 22138; on 26.917 marks continued with runtime_resume_started/finished, history_ready).
maybe_resume_started ... environmentIds=undefined connectedEnvironmentIds=undefined (on 26.917: environmentIds=["local"]).
thread/resume never sent (0 calls), while thread/read / thread/list answer in 2–20 ms and DB is healthy.
Failed to load shell env caller=startup detail="Timed out after 5000ms." on every start (absent before the update).
[managed-worktree-archive-queue] Worktree archive will be retried errorMessage="Git is unavailable" every ~5 min; the probe /bin/sh -c 'command -v git … exec git --version' returns exit 0 when run manually.
codex doctor: state DB healthy, 2 notes (3 rollout files named rollout-…-_.jsonl count as missing in the state DB; 2 duplicate inventory entries).

Looks like the new client-side shell-env/git/environment helper layer blocks thread hydration on Linux. Please investigate.

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

[Linux] Codex Desktop 26.924.x: every conversation hangs on open, thread/resume never reaches app-server #48413
[Linux Desktop][26.924 regression] Existing threads fail to load; terminal TUI opens older threads normally #48397
[Linux Desktop] 26.924.20706 hangs loading existing chats; rollback to 26.917.71314 fixes it #48345
[Linux Desktop][Regression] Codex UI hangs after update; thread_hydration times out while app-server remains responsive #48208
Linux Desktop regression: Codex hangs on every prompt in 26.924.22138, works after downgrade to 26.901.41600 #48417

Powered by Codex Action

👍 Same here — ChatGPT Desktop 26.924.22138, Ubuntu 26.04 (x86_64), Plus plan. After the update, existing chats don't load and prompts in new chats aren't submitted. Restarting the app doesn't help. Everything else (web app, CLI login) works fine.

Same here on Ubuntu 26.04

Additional reproduction and verified rollback on Ubuntu 24.04.5 LTS (amd64), Linux 7.0.0-34-generic.

Affected: official chatgpt DEB 26.924.22138 (build 11645, commit 2e782921399a788a842b74ee1944a2e1e6e003a1).
Working after rollback: official DEB 26.908.70816, bundled codex-cli 0.154.0-alpha.6.2.

The sidebar displayed chat titles and the composer remained visible, but opening any tested existing local Codex chat left an indefinite spinner in the conversation pane. Phone Remote could still read the same chats and send messages to the Linux host while its desktop UI was stuck.

Evidence from the failing version (excerpts trimmed; local paths, conversation/request IDs, and account details omitted):

Failed to load shell env caller=startup detail="Timed out after 5000ms." status=timed_out timeoutMs=5000
response_routed durationMs=2 errorCode=null method=thread/read
name=thread_hydration outcome=failure reason=timeout durationMs=120000.3 marksMs={"writable_roots_ready":15,"metadata_ready":22.7}
Worktree archive will be retried errorMessage="Git is unavailable"

The inspected failing desktop launches had no method=thread/resume entries. Direct Bash login/interactive-shell and Git checks succeeded in about 0.2 seconds; git --version returned 2.43.0.

Troubleshooting and result:

Repeated full app restarts and machine reboots did not help.
Launching from a terminal did not help.
A fresh temporary desktop user-data directory, explicitly selected with --user-data-dir and verified to contain newly created profile files, reproduced the issue. This test retained the existing CODEX_HOME; it was not a clean Codex history/config test.
Backed up app state, then downgraded only the chatgpt package from 26.924.22138 to 26.908.70816, preserving existing chats/config and leaving the updated kernel/system packages installed.
Chats immediately loaded in the Linux desktop again, and this follow-up is being sent from the restored desktop.
In the rollback startup log, the shell-env timeout and Git-unavailable messages were absent, and thread/resume completed with errorCode=null (one observed response: 74 ms).
The package is temporarily held with apt-mark hold chatgpt.

Other Linux/NVIDIA updates occurred around the same time, so the precise root cause is unconfirmed. However, reverting only the desktop package restored functionality on the otherwise unchanged updated system. This corroborates a desktop-version regression or compatibility issue rather than lost chat history.

Fedora-specific note: the downgrade workaround isn't available here.

The official repo (https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64) and the latest RPM URL only serve 26.924.22138 — repodata lists a single version, and versioned paths return 404 (e.g. /rpm/26.908.70816/chatgpt.x86_64.rpm, /rpm/chatgpt-26.908.70816-1.x86_64.rpm).
dnf keeps no old packages in cache (the app was installed via @commandline), so dnf downgrade has nothing to install. Ubuntu users can roll back from /var/cache/apt/archives; Fedora users currently cannot.

Could you please publish the previous build (or a versioned / "previous" package path) for Linux RPM, or share an ETA for the fix?

Confirming again that only the desktop UI is affected: the local app-server answers normally (thread/read 2–20 ms), codex doctor reports a healthy state DB, and both Codex CLI 0.157.1 and Codex Remote work with the same threads. Fedora 44 KDE, kernel 7.2.7, app 26.924.22138 (buildNumber 11645, commit 2e782921).

@farrukh-mirzazade

@farrukh-mirzazade One clarification about the Ubuntu rollback I reported above: the older DEB was not available in my local APT cache. We downloaded 26.908.70816 directly from OpenAI's package server on September 26; this exact URL returned HTTP 200:

https://persistent.oaistatic.com/codex-app-prod/linux/deb/pool/main/c/chatgpt/chatgpt_26.908.70816_amd64.deb

The package metadata confirmed that version, and downgrading only the desktop package restored chat loading with the existing data and updated Linux system intact.

That establishes availability of the older DEB, but I haven't verified an equivalent RPM URL. It would be helpful if the team could provide the supported previous-version RPM download as well, or identify a fixed Linux desktop build.

@JaimeIsMe

Update for Fedora users — the previous RPM is downloadable after all.

There is no pool/ layout for RPMs (all .../linux/rpm/pool/... variants I tried return 404), but older RPM blobs are still served directly from the repo directory:

https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64/chatgpt-26.917.71314-1.x86_64.rpm   (HTTP 200)
https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64/chatgpt-26.915.31945-1.x86_64.rpm   (HTTP 200)
https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64/chatgpt-26.908.70816-1.x86_64.rpm   (HTTP 200)

I verified the first 4 MiB of two of them with rpm -qp — package name/version match exactly. repodata only lists 26.924.22138, which is why dnf downgrade can't see them, but a direct install works:

cd ~/Downloads
curl -fLO https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64/chatgpt-26.917.71314-1.x86_64.rpm
sudo dnf downgrade ./chatgpt-26.917.71314-1.x86_64.rpm

To keep dnf upgrade from pulling the broken build back (Fedora's equivalent of apt-mark hold):

sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add chatgpt

Thanks @JaimeIsMe — your DEB pool pointer is what prompted me to look at the repo directory directly.

@openai Two asks, besides a fixed Linux build: could previous packages be listed in repodata (or this path be documented) so Fedora users aren't stuck? And if possible, please share an ETA — the regression is still reproducible on 26.924.22138 (buildNumber 11645) on Fedora 44.

Confirming the rollback restore on Fedora 44 (KDE, x86_64), with the exact Fedora steps for anyone else stuck.

Installed chatgpt-26.917.71314-1.x86_64.rpm directly from the repo directory (rpm -K → digests signatures OK):

https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64/chatgpt-26.917.71314-1.x86_64.rpm

sudo dnf downgrade ./chatgpt-26.917.71314-1.x86_64.rpm
sudo dnf versionlock add chatgpt        # hold until a fixed build is available

Result: chats load again immediately, with existing data and settings intact.

Post-downgrade logs: 3× thread_hydration outcome=success, thread/start works for new chats, thread/resume requests are accepted again, and both Failed to load shell env and Git is unavailable are gone. (Downgrading only the desktop package was enough; no changes to ~/.codex were needed.)

Still waiting for a fixed Linux build — the regression remains reproducible on 26.924.22138 (buildNumber 11645), and repodata still exposes only that build, so Fedora users need the direct URL above to roll back.

Root cause found (Linux, ChatGPT Desktop 26.924.20706 and 26.924.22138), with a working fix that needs no downgrade.

Cause: after startup, the app's Electron runtime installs an empty SIGCHLD handler with sigaction, replacing libuv's handler. libuv installs its SIGCHLD handler only once (on the first child it spawns), so from then on the main process never reaps a child. Every child_process await in the main process hangs, which produces exactly the symptoms reported here and in #48397, #48225 and #48417:

Failed to load shell env ... Timed out after 5000ms
Git is unavailable although git works from a terminal
thread_hydration ... outcome=failure reason=timeout, and thread/resume is never sent
new messages queue and new threads never start

How to confirm on your machine:

ps -o pid,stat,comm --ppid $(pgrep -o -x ChatGPT) shows Z (zombie) bash, git, ps and codex children piling up.
A bpftrace probe of signal:signal_deliver for sig 17 on the ChatGPT main process shows SIGCHLD delivered, with no wait4/waitid and no write to libuv's signal pipe afterwards.
The installed handler resolves (through a CFI jump table) to an empty function.

Workaround: preload a small shared library that refuses only that replacement, i.e. a sigaction(SIGCHLD, ...) call whose handler is an empty function while a real handler is already installed. It passes every other call through and removes itself from LD_PRELOAD so child processes don't inherit it. Launch the app with LD_PRELOAD=/path/to/guard.so /usr/lib/chatgpt/ChatGPT (not through the chatgpt shell wrapper, which would consume the preload). Tested in an isolated headless A/B on 26.924.22138:

without the guard: 5+ zombies and the shell-env timeout;
with the guard: 0 zombies, the shell env loads, threads resume, messages send and new threads start.

Core of the guard (x86-64):

int sigaction(int sig, const struct sigaction *act, struct sigaction *old) {
    if (sig == SIGCHLD && act && !(act->sa_flags & SA_SIGINFO)
            && act->sa_handler != SIG_DFL && act->sa_handler != SIG_IGN
            && is_empty_function(act->sa_handler)) {   /* follow endbr64/jmp, then `ret` or push/mov/pop/ret */
        struct sigaction cur;
        if (real_sigaction(SIGCHLD, NULL, &cur) == 0 && cur.sa_handler != SIG_DFL && cur.sa_handler != SIG_IGN) {
            if (old) *old = cur;
            return 0;   /* keep libuv's reaper */
        }
    }
    return real_sigaction(sig, act, old);
}

Suggested fix: don't install a SIGCHLD handler in the Electron runtime after Node/libuv has installed one, or chain to the previous handler. Related: #38505 (zombie accumulation on macOS).

Additional Fedora 44 diagnostics for ChatGPT Desktop 26.924.22138-1:

Environment

Fedora 44 x86_64
Kernel 7.2.7-200.fc44.x86_64
ChatGPT Desktop 26.924.22138-1
Bundled Electron version file: 42.3.0
AMD Phoenix1 / amdgpu / Mesa 26.2.3

Reproducible finding
Every examined app launch hits a shell-environment timeout at ~5 seconds:

Existing profile launches: ~5012–5014 ms
Fresh isolated profile, GPU enabled: 5013 ms
Fresh isolated profile, --disable-gpu: 5014 ms

By contrast, directly invoking the bash login shell and Git outside the app completes successfully in ~0.212 s.

This suggests the timeout is specific to the app's shell-environment/subprocess integration rather than the shell or Git itself.

Other relevant observations

Existing-session logs contain 39 worktree-archive retries reporting "Git is unavailable"
Git is installed and works normally when invoked directly
--disable-gpu removed observed VSync timing errors but did not improve the shell timeout
Main frame/window initialization after the timeout is relatively fast (~268 ms frame load, ~522 ms ready-to-show)
Repeated MaxListenersExceededWarning messages occur with both existing and fresh profiles
No ChatGPT coredumps observed
No AMD GPU reset/hang observed
No obvious Chromium/LevelDB corruption found

App paths

/usr/bin/chatgpt -> /usr/lib/chatgpt/codex-launcher
Real executable: /usr/lib/chatgpt/ChatGPT
Bundled backend: /usr/lib/chatgpt/resources/codex
Main logs: ~/.local/state/codex/logs/

Important limitation
The ~5s shell-environment timeout is reproducible, but I have not established that it is the direct cause of the intermittent authenticated hangs. That would still need a matched workload reproduction or hang trace.

No existing profile/config was deleted or modified during testing.

Same here.
I can't update beyond 26.917.71314
I tried updating to 26.924.22138 and the chats would not start.
I had the same issue with 26.924.20706 and had to downgrade.

Feedback ID: 01a0dfe4-b50d-7261-9ee8-d02ac8e2fe22

Update history:
026-09-23 19:44:28 upgrade chatgpt:amd64 26.917.51856 26.917.62051
2026-09-24 16:29:25 upgrade chatgpt:amd64 26.917.62051 26.917.71314
2026-09-26 11:47:19 upgrade chatgpt:amd64 26.917.71314 26.924.20706
2026-09-26 12:11:21 upgrade chatgpt:amd64 26.924.20706 26.917.71314 [First downgrade]
2026-09-27 08:32:17 upgrade chatgpt:amd64 26.917.71314 26.924.22138 [New 26.924.x, tried updating, same issue]
2026-09-27 08:44:43 upgrade chatgpt:amd64 26.924.22138 26.917.71314 [Second downgrade]

===== OS =====
OS: Ubuntu 26.04.1 LTS
Kernel: Linux 7.0.0-34-generic x86_64 GNU/Linux
glibc: glibc 2.43

===== Desktop / session =====
Desktop: ubuntu:GNOME
Session type: wayland
Wayland display: wayland-0
X11 display: :0
GNOME Shell 50.1

===== CPU / memory =====
Architecture: x86_64
CPU(s): 16
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) Ultra 7 356H
total used free shared buff/cache available
Mem: 30Gi 4.7Gi 2.9Gi 601Mi 23Gi 25Gi
Swap: 8.0Gi 715Mi 7.3Gi

===== GPU / graphics driver =====
00:02.0 VGA compatible controller [0300]: Intel Corporation Panther Lake [Intel Graphics] [8086:b0a0]
DeviceName: Onboard - Video
Subsystem: ASUSTeK Computer Inc. Device [1043:891e]
Kernel driver in use: xe
Kernel modules: xe

===== Graphics stack =====
glxinfo: not installed
vulkaninfo: not installed

===== Relevant libraries =====
libdrm2 2.4.131-1
libgbm1 26.0.8-1ubuntu0.3
libgtk-3-0
libnss3 2:3.120-1ubuntu2.1
mesa-vulkan-drivers 26.0.8-1ubuntu0.3

I can confirm the issue on Arch Linux with chatgpt-bin 26.924.22138-1. The branch/worktree controls were missing, with Git is unavailable and a 5000 ms shell environment timeout in the logs. Git worked normally in the terminal, and the desktop process accumulated zombie Git and Fish (my default shell) children.
Restarting and changing the remote from SSH to HTTPS did not help. Rolling back to 26.917.71314 restored the worktree controls.

same here with 26.924.22138.same shell environment timeout.

Confirming the same symptoms on Pop!_OS 24.04 LTS with the official .deb package:

Updated from 26.917.71314 to 26.924.22138.
The application interface opened, but conversations and content would not load, making everything appear missing.
Rolling back to 26.917.71314 restored access.

This confirms the affected/working version pair on another Linux distribution. I have not independently verified the proposed helper-process root cause.

Experiencing this, rolling back to 26.917 fixed it temporarily for me as well

This is now resolved for me on 26.924.50649. Thanks.

The issue has been fixed. Please update to the latest version.

Navigation Menu

Repository navigation

linux desktop app 26.924 hangs on opening any local Codex thread — hydration never sends thread/resume, 120s timeout #48419

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

linux desktop app 26.924 hangs on opening any local Codex thread — hydration never sends thread/resume, 120s timeout #48419

Description

Activity

github-actions commented on Sep 26, 2026

marwanvx commented on Sep 26, 2026

abhikhurana1 commented on Sep 26, 2026

JaimeIsMe commented on Sep 26, 2026

farrukh-mirzazade commented on Sep 26, 2026

JaimeIsMe commented on Sep 26, 2026

farrukh-mirzazade commented on Sep 26, 2026

farrukh-mirzazade commented on Sep 26, 2026

axusnetworks commented on Sep 26, 2026

paolo-arge-lf commented on Sep 27, 2026

fn5 commented on Sep 27, 2026

domcyrus commented on Sep 27, 2026

oncehere commented on Sep 27, 2026

Dragon-Lady commented on Sep 27, 2026

F3Services commented on Sep 27, 2026

fn5 commented on Sep 28, 2026

yuzhu-oai commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions