[Linux Desktop][Regression] Codex UI hangs after update; thread_hydration times out while app-server remains responsive

Summary

After the most recent Codex/ChatGPT desktop update on Ubuntu, the Codex desktop UI opens but a Codex chat remains stuck on the loading spinner and cannot be interacted with.

This started immediately after the update.

Environment

OS: Ubuntu 24.04
Platform: Linux desktop app
Bundled Codex CLI: codex-cli 0.158.0-alpha.2
Desktop log build number: 11431
Desktop log build commit: 97cf4a3c7cee97ad6cbb13cb9ab228321db3a385

Reproduction

Launch the desktop app normally.
Open Codex / an existing Codex chat.
The chat remains stuck loading indefinitely.
After roughly 5 minutes, the desktop log records a thread hydration timeout.

Relevant sanitized log evidence

The app-server itself appears responsive: requests such as configRequirements/read, thread/attachment/list, and model/list complete in a few milliseconds with errorCode=null.

The UI/thread hydration path then times out:

name=thread_hydration outcome=failure reason=timeout durationMs=304709.7 wallDurationMs=304710

A later retry shows the same failure:

name=thread_hydration outcome=failure reason=timeout durationMs=314626.2 wallDurationMs=314627

There is also a potentially unrelated worktree archive warning:

Worktree archive will be retried errorMessage="Git is unavailable"

Request IDs, conversation IDs, username, and local paths have been omitted/redacted.

Additional observation

The bundled Codex binary itself can run with:

/usr/lib/chatgpt/resources/codex --no-daemon

That launches the interactive Codex CLI, so the bundled binary is present and executable. The problem described here is specifically the desktop Codex UI/thread loading path.

Expected behavior

The Codex thread should hydrate and become interactive shortly after the desktop app launches.

Actual behavior

The Codex chat remains on the loading spinner and repeatedly times out during thread_hydration, even though app-server requests continue to return successfully.

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

[Linux] Cannot open any previous chats after update, stuck on Loading #48171
[Linux] Codex Desktop 26.924.20706 hangs indefinitely on "Starting your task"; rollback to 26.917.71314 fixes it #48189

Powered by Codex Action

same issue on Ubuntu 26.04

Same here. On Debian GNU/Linux forky/sid (amd64), KDE Plasma 6.6.5 on X11 (Qt 6.10.2), updating ChatGPT Desktop from 26.917.71314 to 26.924.20706 (build 11431) left existing Codex threads stuck on the loading spinner. Downgrading to 26.917.61114 restored normal loading.

Same here. On Linux Mint 22.3 (amd64), Cinnamon 6.6.9 on X11, updating ChatGPT Desktop from 26.917.71314 to 26.924.20706 left existing conversations stuck on the loading spinner, and new messages kept loading indefinitely. Downgrading back to 26.917.71314 restored normal behavior.

I can reproduce a very similar regression on CachyOS / Arch Linux.

Environment:

OS: CachyOS (Arch Linux based)
ChatGPT desktop package: repackaged from the official Linux .deb using chatgpt-arch
Broken version: 26.924.22138-2
Working version: 26.901.51231-2

After updating ChatGPT Desktop to 26.924.22138-2, Codex stopped working correctly.

I downgraded the application back to 26.901.51231-2, and Codex immediately started working normally again.

Downgrade method used:

cd ~/chatgpt-arch
mkdir -p dist
PKGDEST="$PWD/dist" makepkg --cleanbuild

sudo pacman -U ~/chatgpt-arch/dist/chatgpt-26.901.51231-2-x86_64.pkg.tar.zst

I then launched the working version while skipping the desktop update check:

CHATGPT_SKIP_UPDATE_CHECK=1 chatgpt

So in my case the regression is clearly tied to the newer desktop build: 26.924.22138 fails, while 26.901.51231 works on the same CachyOS installation.

This may also indicate that the issue is not Ubuntu-specific.

Additional clean A/B confirmation on LMDE 7 (Debian-based Linux, amd64) using the official .deb packages:

Broken: 26.924.22138 — the app launches normally, but the same existing local Codex task remains stuck loading. Restarting the app did not help.
Working: 26.908.70816 — after downgrading from the locally cached package, the exact same task immediately loaded normally.
No task data, workspace, account, authentication, or configuration changes were made. I did not clear or reset local app data.

The broken build came from the OpenAI APT repository:
https://persistent.oaistatic.com/codex-app-prod/linux/deb

There was a Codex/OpenAI service incident during the same general period, but the failure persisted on 26.924.22138 and disappeared immediately after rolling back to 26.908.70816. This same-machine, same-task A/B result strongly suggests a desktop regression rather than task corruption or a service-only failure.

I can provide additional sanitized diagnostics if maintainers specify which Linux desktop-app logs would be most useful.

Additional deterministic rollback evidence from Linux.

Environment

Linux Mint Cinnamon, amd64
ChatGPT/Codex Linux .deb
Bundled app-server on affected build: 0.158.0-alpha.2.1

Sequence

Codex was working normally.
A prompt failed with a 401 Unauthorized / Incorrect API key response against https://chatgpt.com/backend-api/codex/responses.
I closed the desktop app and installed the pending update.
After restart, the sidebar/task list still populated normally, but selecting an existing thread produced a blank conversation body.
Rebooting the machine did not resolve it.
26.924.20706 exhibited the problem.
Updating to 26.924.22138 did not resolve it.

Diagnostics on 26.924.22138

thread/list succeeds with errorCode=null
thread/read for the affected thread succeeds with errorCode=null
thread/queue/list succeeds with errorCode=null
Renderer logs:
- thread_stream_view_activity_changed ... resumeState=needs_resume
- maybe_resume_started ... hostId=local ... vmEvent=thread_resume_requested
- no corresponding observed resume completion
- Received broadcast but no handler is configured method=thread-stream-following-changed
There is also a PromiseRejectionHandledWarning immediately before the resume path.
Some chatgpt.com/ces/v1/... requests receive Cloudflare managed-challenge HTML and the renderer subsequently logs Uncaught (in promise) RequestError: Something went wrong. I do not know whether this is causal or secondary.

Profile/cache isolation
I launched 26.924.22138 with a completely disposable Electron profile:

--user-data-dir="$(mktemp -d /tmp/chatgpt-clean-profile.XXXXXX)"

The app opened successfully and was authenticated, but threads still did not hydrate.

This appears to rule out normal Electron profile state, Local Storage, Session Storage, cookies, or cache as the primary cause.

Rollback test
The same machine had older .deb packages cached locally.

I downgraded directly from:

26.924.22138

to:

26.917.71314

without modifying ~/.config/Codex, ~/.codex, session files, rollout data, or databases.

After rollback, the exact same previously blank thread immediately hydrated and worked normally.

I then sent a new prompt through that restored thread successfully.

So on this machine:

26.917.71314 = working
26.924.20706 = blank thread body
26.924.22138 = blank thread body
same profile/data/thread across rollback
clean disposable Electron profile also fails on 26.924.22138

This makes the 26.924 Linux desktop line look like the regression boundary rather than local thread corruption.

I have retained the debug logs and both affected/working .deb packages if more targeted diagnostics would help.

Additional Fedora 44 reproduction and verified RPM rollback recovery

Adding another Linux reproduction with the same thread_hydration timeout signature, observed on September 26, 2026. The exact underlying cause has not been established.

Environment

Fedora Linux 44 KDE Plasma Desktop Edition, x86_64.
Plasma 6.7.5, Wayland session, Fcitx5 5.1.22.
Official OpenAI RPM package: chatgpt.
Affected build captured in the logs: 26.924.22138-1, desktop build number 11645, commit 2e782921399a788a842b74ee1944a2e1e6e003a1.
Existing per-app launch arguments: --ozone-platform=wayland --enable-wayland-ime --wayland-text-input-version=3. These were in use before the failure and are also in use in the recovered state.

Observed behavior

Existing conversations remained stuck loading, and starting a new conversation was also unusable.
Mobile remote access to the same computer continued to work.
Rebooting the computer did not resolve the desktop failure.
Local app-server RPCs, including thread/read, thread/list, config/read, and configRequirements/read, continued returning successfully. Thread reads around failed navigation attempts completed in a few milliseconds with errorCode=null.

Selected log fields, with identifiers and paths removed

name=thread_navigation outcome=failure reason=timeout durationMs=30000 timingQuality=foreground
name=thread_hydration outcome=failure reason=timeout durationMs=120000.2 marksMs={"writable_roots_ready":32.3,"metadata_ready":44.6} timingQuality=foreground
name=thread_hydration outcome=failure reason=timeout durationMs=120000.1 marksMs={"writable_roots_ready":22.6,"metadata_ready":35.8} timingQuality=foreground

The UI therefore reached writable-root and metadata readiness quickly, then timed out later in chat initialization. I am not inferring a specific blocked dependency from these marks.

Version history and recovery

26.917.71314-1: working on September 25; working again after rollback on September 26.
26.924.20706-1: installed earlier on September 26, during the period when the problem began. The detailed capture above is from the subsequent build, so this is not a separately controlled test of 20706.
26.924.22138-1: existing and new conversations unusable; reboot did not recover them.

Downgrading the official RPM from 26.924.22138-1 to 26.917.71314-1 restored conversation loading and interaction. Session files and databases were backed up, but were not reset or replaced from backup, and the existing signed-in app profile was retained. The recovered app continues working with the same native Wayland launch arguments listed above.

This provides another distribution/package-format example and a working rollback version. It does not establish that the cause is identical across every report in this issue.

Could a maintainer confirm whether this regression is being tracked internally, and identify the desktop build containing a fix when one is available?

Confirming this regression on Arch Linux / Hyprland.

Versions tested

26.917.61114-1 — works
26.924.20706-1 — broken
26.924.22138-1 — broken
Downgrading back to 26.917.61114-1 immediately restores normal behavior

Behavior

The desktop app launches and renders normally, but chats/tasks remain stuck indefinitely on “Starting your task” / a loading spinner.

The bundled app-server itself appears healthy:

[AppServerConnection] Transport start success
initialize_handshake_result ... outcome=success
[AppServerConnection] Codex CLI initialized
... next=connected

Still reproducible on Linux desktop build 11645
(commit 2e782921399a788a842b74ee1944a2e1e6e003a1).

My current ChatGPT Desktop version is 26.924.22138.

The app-server remains responsive, but local thread hydration still
times out. The logs also still contain:

managed-worktree-archive-queue:
"Git is unavailable"

Local route creation succeeds, for example:

/local/client-new-thread:...

I also verified that Git itself is installed and accessible from the
Codex app-server environment:

/usr/bin/git
git version 2.55.0

Cloud Work continues to work normally, while local Work hangs at
"Your task is starting".

So the regression reported here for build 11431 appears to persist
in build 11645.

Got same issue
Kubuntu 26.04 LTS
Kernel 7.0.0-34-generic
KDE Plasma + Wayland
NVIDIA RTX 4060 Laptop
NVIDIA 595.91.07
Codex Desktop 26.924.20706
Codex CLI 0.157.1
Desktop broken, CLI works

Confirming this regression on Ubuntu 22+ using the official .deb packages:

Broken version: 26.924.22138
Last working version: 26.917.51856

After updating ChatGPT Desktop to 26.924.22138, Codex stopped working correctly.

The broken build came from the OpenAI APT repository: https://persistent.oaistatic.com/codex-app-prod/linux/deb

26.924.x - broken

I downgraded the application back to a working Ubuntu build 26.917.71314.

A list of all the stable releases *.deb build that came from the OpenAI APT repository in the last one month:

ChatGPT 26.924.x app UI got updated with a new sidebar, separated from the chat history:

what happened to move fast and don't break things?

same issue on Ubuntu 24.04.5 LTS

I can reproduce this on Ubuntu 24.04.5 LTS (x86_64) with the official chatgpt .deb, version 26.924.22138 (desktop build 11645; bundled codex-cli 0.158.0-alpha.2.1). Both existing and new Codex/Work conversations remain on a blank pane with a loading spinner. The sidebar and project list render. ChatGPT conversations open normally in a browser on the same machine, and mobile remote access to this host works.

The package passes dpkg -V chatgpt, and the local Codex state, thread-history, and logs SQLite databases pass PRAGMA quick_check. The problem persisted after a full app restart, display-cache reset, local page-storage reset, and sign-out/sign-in. I also tested resetting the saved desktop state, then restored it because it did not help. Conversation files were not removed.

Selected sanitized journal fields:

Failed to load shell env caller=startup detail="Timed out after 5000ms." status=timed_out timeoutMs=5000
name=thread_navigation outcome=failure reason=timeout durationMs=30000.6 threadKind=local threadState=cold
name=thread_hydration outcome=failure reason=timeout durationMs=120000.3 marksMs={"writable_roots_ready":29.1,"metadata_ready":34.4}
method=thread/read errorCode=null durationMs=1
method=thread/list errorCode=null durationMs=1
sa_server_request_failed errorMessage="Workspace routing is unavailable" status=432 routePattern=/wham/tasks/list
sa_server_request_failed errorMessage="Desktop network policy does not allow this destination" status=500 routePattern=/wham/tasks/list

The routing errors may be separate from the thread hydration timeout; I cannot establish a common cause from these logs. This reproduces the spinner and responsive app-server behavior in this issue on another Ubuntu machine. Please investigate the Linux desktop hydration path in 26.924.x and provide a fixed build or supported rollback guidance.

I’m seeing the same issue after updating from 26.917.71314:

Fedora Linux 44 Workstation, kernel 7.1.12-200.fc44.x86_64
GNOME on Wayland
NVIDIA GeForce GTX 1650 Ti, driver 610.57.04
Codex Desktop 26.924.22138; Codex CLI 0.157.0

Existing threads stay on the spinner, and new threads stay on “Starting your task.” The CLI works. Desktop logs show successful thread/read responses, followed by thread_navigation outcome=failure reason=timeout. Restarting and moving the UI cache and saved session state aside did not help

I am experiencing the same Linux Codex Desktop issue, and it has now been blocking my work for almost 24 hours.

I use Codex as my primary development environment and I currently have multiple active projects that need to be completed and launched, so I would really appreciate this Linux issue being investigated and fixed as soon as possible.

I have spent several hours troubleshooting it and I think I have managed to isolate the problem quite well.

SYSTEM

Ubuntu Linux
HP Z240 workstation
ChatGPT Pro account
Codex Desktop 26.924.20706 initially
Codex Desktop 26.924.22138 currently
Bundled Codex CLI: 0.158.0-alpha.2

THE PROBLEM

Codex Desktop opens normally, I can access my projects and create new chats, but every Codex task remains indefinitely at:

"Starting your task"

Even something as simple as:

"say hello"

never starts.

This happens in existing projects as well as completely new chats.

WHAT MAKES THIS PARTICULARLY INTERESTING

The ChatGPT mode inside the SAME Linux desktop application works perfectly.

So, on the same machine and inside the same application:

ChatGPT mode -> WORKS
Codex mode -> DOES NOT WORK

I can switch from Codex to ChatGPT in the application, send a message, and ChatGPT responds immediately.

WINDOWS TEST

I also have Codex Desktop installed on a Windows 10 laptop.

I logged into it using the exact same OpenAI account.

The Windows laptop is connected to the same home network and uses the same Internet connection as the Linux workstation.

Codex Desktop on Windows works normally.

So:

Windows 10 + same account + same network -> WORKS
Ubuntu Linux + same account + same network -> Codex stuck on "Starting your task"

CODEX CLI ON THE SAME LINUX MACHINE

I then tested the bundled Codex CLI directly on the Linux workstation:

/usr/lib/chatgpt/resources/codex --no-daemon

It works.

Codex responds normally and can execute prompts.

I also explicitly tested GPT-5.5 through the CLI and it responded correctly.

Therefore, on exactly the same Ubuntu machine:

Codex CLI -> WORKS
Codex Desktop -> DOES NOT WORK

This also strongly suggests that my ChatGPT Pro account, Codex access, usage allocation and model access are working correctly.

WHAT I HAVE ALREADY TRIED

Reinstalled Codex Desktop from the official OpenAI APT repository.

sudo apt install --reinstall chatgpt

No change.

Completely reset the Linux Desktop profile.

I moved ~/.config/Codex out of the way and allowed the application to generate a completely new profile.

No change.

While troubleshooting, OpenAI published a newer Linux build in the official APT repository.

I was originally running:

26.924.20706

After:

sudo apt update

the repository offered:

26.924.22138

I upgraded immediately.

No change.

After upgrading to 26.924.22138, I again removed the newly created desktop profile from the equation and allowed 26.924.22138 to start with a completely fresh ~/.config/Codex.

Still no change.

Codex remains indefinitely at "Starting your task".

Tested the firewall.

My normal UFW configuration is:

deny incoming
allow outgoing

I completely disabled UFW and rebooted the workstation with the firewall disabled.

Codex Desktop still did not work.

I have since re-enabled UFW.

Changed my public IP address.

No change.

Tested IPv4 and IPv6 separately.

Both routes reach chatgpt.com.

curl does receive:

HTTP/2 403
cf-mitigated: challenge
server: cloudflare

I also found Cloudflare managed-challenge HTML / NetworkError entries in the Codex Desktop logs.

However, I do not believe this represents a general connectivity problem on the workstation because all of the following work from the exact same Linux machine:

ChatGPT in Firefox
ChatGPT in Google Chrome
ChatGPT mode inside the same Linux Desktop application
Codex CLI using --no-daemon

Additionally, Codex Desktop works on my Windows 10 laptop through the same Internet connection.

Checked for proxy configuration.

There are no HTTP_PROXY, HTTPS_PROXY, ALL_PROXY or related proxy environment variables configured.

Checked /etc/hosts.

Nothing unusual is configured there.

Checked certificate-related environment overrides.

There are no SSL_CERT, CURL_CA, NODE_EXTRA_CA or REQUESTS_CA overrides configured.

LOGS

The Linux Desktop logs contain errors including:

"RequestError: Something went wrong"

and:

"Worktree archive will be retried errorMessage="Git is unavailable""

There are also some requests to chatgpt.com that receive Cloudflare managed-challenge responses.

CURRENT TEST MATRIX

Ubuntu Linux - ChatGPT Desktop mode:
WORKS

Ubuntu Linux - Codex Desktop mode:
FAILS - stuck indefinitely on "Starting your task"

Ubuntu Linux - Codex CLI --no-daemon:
WORKS

Ubuntu Linux - Firefox / ChatGPT:
WORKS

Ubuntu Linux - Chrome / ChatGPT:
WORKS

Windows 10 - Codex Desktop:
WORKS

The Windows and Linux machines use:

the same OpenAI account
the same ChatGPT Pro subscription
the same home network
the same Internet connection

LINUX DESKTOP BUILDS TESTED

26.924.20706:
FAILS

26.924.22138:
FAILS

26.924.22138 with a completely fresh ~/.config/Codex:
FAILS

CONCLUSION

After all these tests, the problem appears to be specifically related to Codex task execution / app-server integration in the Linux Desktop application.

The machine itself can access OpenAI normally.

The account works.

The models work.

Codex CLI works.

ChatGPT works in both browsers and inside the same Linux desktop application.

Codex Desktop works on Windows with the same account and network.

Only Codex mode inside the Linux Desktop application is unable to start tasks.

This has been happening for almost 24 hours now and it is seriously affecting my work.

I have multiple development projects that I need to finish and launch, and this Linux workstation is my primary Codex development environment.

I would really appreciate it if this regression could be investigated and fixed as soon as possible.

If the OpenAI/Codex maintainers need additional logs, system information or want me to run specific diagnostic commands or test a candidate fix/build on this machine, I am happy to help.

Still reproducible on Linux with ChatGPT App 26.924.22138.
All existing conversations remain stuck on Loading and cannot be opened.

UPDATE: I found a working workaround.

After all the troubleshooting described above, I downgraded the Linux Desktop application to an older official OpenAI package that was still available in my local APT cache:

26.908.40834

Result: Codex Desktop immediately started working again.

The exact same machine/configuration behaved as follows:

26.924.20706 -> FAILS, stuck indefinitely on "Starting your task"
26.924.22138 -> FAILS, stuck indefinitely on "Starting your task"
26.908.40834 -> WORKS normally

No other system changes were required.

I used the official OpenAI package that was already present in:

/var/cache/apt/archives/chatgpt_26.908.40834_amd64.deb

I first verified the package:

dpkg-deb -f /var/cache/apt/archives/chatgpt_26.908.40834_amd64.deb Package Version Architecture Maintainer

Output:

Package: chatgpt
Version: 26.908.40834
Architecture: amd64
Maintainer: OpenAI support@openai.com

Then I downgraded with:

sudo apt install --allow-downgrades /var/cache/apt/archives/chatgpt_26.908.40834_amd64.deb

After restarting the application, Codex mode started executing tasks normally again instead of remaining on "Starting your task".

I have temporarily placed the package on hold:

sudo apt-mark hold chatgpt

so APT does not automatically upgrade it back to one of the affected builds.

This seems to confirm a Linux Desktop regression introduced sometime after 26.908.40834.

One important detail: I also tested increasing:

fs.inotify.max_user_instances

from 128 to 1024 before the downgrade, but that did NOT fix the issue on 26.924.22138.

So in my case the working solution was specifically the rollback to 26.908.40834.

Hopefully this helps other Linux users who are currently blocked.

I will stay on 26.908.40834 until there is confirmation that a newer Linux build contains a fix for this regression.

Thanks, and I hope this can be fixed soon — I have multiple active projects that need to be completed and launched.

If Codex releases a new update and it works, we would appreciate it if you let us know here guys

Additional Ubuntu 24.04 reproduction with a controlled version comparison:

OS: Ubuntu 24.04 x86_64
Working desktop build before upgrade: 26.917.62051
Failing desktop build: 26.924.20706
Symptoms on the failing build:
1. Existing/local Codex conversations remain on an infinite loading spinner.
2. Brand-new local tasks remain indefinitely on "Starting your task".
Downgrading only the ChatGPT Desktop package back to 26.917.62051 restores normal behavior with the same account and the same ~/.codex data.

Diagnostics already performed on the failing build:

ChatGPT authentication is healthy.
Backend HTTP/WebSocket connectivity is healthy.
Standalone/bundled Codex text inference works.
codex doctor reports state DB, thread history DB, rollout inventory, etc. as healthy (no missing/stale rollout rows).
Bubblewrap/AppArmor initially reproduced a separate Ubuntu 24.04 sandbox failure. I installed the targeted bwrap AppArmor profile and verified that:
- bwrap --ro-bind / / true -> exit 0
- bwrap --unshare-net --ro-bind / / true -> exit 0
- /usr/lib/chatgpt/resources/codex sandbox -- /bin/pwd -> succeeds
Even after the sandbox path was fixed and the desktop app was fully restarted, the two desktop symptoms remained unchanged.

This makes the Desktop UI/app-server/thread hydration/task dispatch path look like the remaining failure point rather than auth, backend reachability, ~/.codex corruption, or Bubblewrap/AppArmor.

The failure appeared immediately after the 26.917.62051 -> 26.924.20706 package upgrade. Reverting to the 26.917 build is currently the reliable workaround.

Having the same issue on Ubuntu, I had to revert to version Codex 26.917.71314

Additional reproduction on Ubuntu 24.04.4 LTS (kernel 6.8.0-139-generic, amd64), with a clean A/B on the official .deb packages:

Working: 26.908.40834 (bundled codex-cli 0.154.0-alpha.6.2) — existing local conversations load normally.
Broken: 26.924.22138 (bundled codex-cli 0.158.0-alpha.2.1) — existing conversations do not appear; the sidebar sits on a loading spinner.

Additional observations on the broken build:

Local data is intact: state_5.sqlite holds the same 270 threads, PRAGMA quick_check returns ok, and all rollout_path files exist with consistent projection offsets. Nothing is lost.
The app-server side is healthy. Using a bidirectional stdio proxy between the desktop app and the bundled codex app-server, I captured thread/list request/response pairs completing successfully (4 requests / 4 responses) in the same session where the UI still showed the spinner. So thread/list itself is not hanging; the stall is in the app-side consumption/hydration path, which matches the thread_hydration timeouts reported above.
On the broken build, thread/list is re-issued roughly once per second while the UI spins (e.g. at 14:31:06, :07, :08, :09), consistent with a retry loop beating against a hydration that never settles.
thread/resume is called ~49 times during one startup on the broken build, which the working build does not do.

One thing I could NOT confirm, and want to flag against a mistaken fix: I initially suspected rollout_migration_state.last_checked_thread_created_at, which on this machine is written ~8h in the future relative to threads.created_at (local time stored as UTC). However, that same offset is present on the working 26.908.40834 build, so it does not appear to be the trigger. Similarly, the low projected-turn coverage (105 / 270 threads) matches the working build's backup, so it looks normal rather than related.

Downgrading is not a free workaround, by the way: 26.908.40834 does not ship the newer model ids (gpt-6-sol, gpt-6-luna) that 26.924.22138 includes, so users on the older build lose those. That is the reason to upgrade, and currently the two goals are mutually exclusive.

Confirmed on Ubuntu x86_64 (kernel 7.0.0-34-generic, glibc 2.43) with 26.924.22138, build 11645.

All existing sessions were stuck loading. thread/read succeeded, but thread_hydration timed out. Bash/Git children remained zombies after exiting; tracing showed SIGCHLD received without the affected child being reaped. Logs also showed shell-env timeouts and Git is unavailable.

Downgrading only the desktop package to 26.917.71314 restored session loading and child-process cleanup. Two previously failing sessions were verified in the UI. No history deletion, database repair, or login reset was needed. The exact underlying cause is still unconfirmed.

Additional reproduction on Ubuntu 24.04.5 LTS x86_64 with KDE Plasma and ChatGPT Desktop package 26.924.22138 from the official OpenAI Debian repository.

In a new Codex conversation, sending a short message such as test leaves the composer spinning indefinitely.
The bundled app-server stdio handshake succeeds; this is not an initial login or transport failure.
The system Git is present and works: /usr/bin/git, Git 2.43.0.
The desktop logs repeatedly report Worktree archive will be retried errorMessage="Git is unavailable" and the app leaves exited git children as zombies.
dpkg -V chatgpt is clean; available RAM and disk space are sufficient.
Downgrading only the desktop package to 26.917.71314 restored the Codex send path locally, without deleting history or resetting login.

This appears to be the same regression family as this issue and #48640, with the additional observation that the failed Git/worktree probe blocks new-thread submission on the affected package.

Follow-up confirmation on the same LMDE 7 (amd64) machine:

26.924.22138: existing local Codex task fails to load
26.908.70816: same task works after rollback
26.924.50649: same task now hydrates normally and is interactive; I successfully sent a prompt

The update to 26.924.50649 was installed from the official OpenAI APT repository through Update Manager. No task data, workspace, account, authentication, or configuration reset was needed.

Confirming this regression on Ubuntu 22+ using the official .deb packages:
* Broken version: `26.924.22138`

* Last working version: `26.917.51856`
After updating ChatGPT Desktop to 26.924.22138, Codex stopped working correctly.

The broken build came from the OpenAI APT repository: https://persistent.oaistatic.com/codex-app-prod/linux/deb

26.924.x - broken

I downgraded the application back to a working Ubuntu build 26.917.71314.

A list of all the stable releases *.deb build that came from the OpenAI APT repository in the last one month:

ChatGPT 26.924.x app UI got updated with a new sidebar, separated from the chat history:

what happened to move fast and don't break things?

Fixed in 26.928.20755. Thank you.

Navigation Menu

Repository navigation

[Linux Desktop][Regression] Codex UI hangs after update; thread_hydration times out while app-server remains responsive #48208

Summary

Environment

Reproduction

Relevant sanitized log evidence

Additional observation

Expected behavior

Actual behavior

Additional Fedora 44 reproduction and verified RPM rollback recovery

Versions tested

Behavior

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Linux Desktop][Regression] Codex UI hangs after update; thread_hydration times out while app-server remains responsive #48208

Description

Summary

Environment

Reproduction

Relevant sanitized log evidence

Additional observation

Expected behavior

Actual behavior

Activity

github-actions commented on Sep 25, 2026

cpogdjl21 commented on Sep 26, 2026

ShinoharaHaruna commented on Sep 26, 2026

haoyuehx commented on Sep 26, 2026

furkangorur-obs commented on Sep 26, 2026

hexspa commented on Sep 26, 2026

rotolock commented on Sep 26, 2026

badwordsno commented on Sep 26, 2026

Additional Fedora 44 reproduction and verified RPM rollback recovery

abhiyandhakal commented on Sep 26, 2026

Versions tested

Behavior

cantfixitwhatamidoing commented on Sep 26, 2026

wu5810222-alt commented on Sep 26, 2026

cedrickchee commented on Sep 26, 2026

3 remaining items

076ste-dev commented on Sep 26, 2026

J-K-Ellis commented on Sep 26, 2026

sin4ch commented on Sep 26, 2026

seomarketingsolutionssrl commented on Sep 26, 2026

xiaozhangup commented on Sep 26, 2026

seomarketingsolutionssrl commented on Sep 26, 2026

furkangorur-obs commented on Sep 26, 2026

JalenLoong commented on Sep 27, 2026

Jey-molokoy commented on Sep 27, 2026

loocoo2025 commented on Sep 27, 2026

shin4 commented on Sep 27, 2026

matkielesinski-cmd commented on Sep 27, 2026

hexspa commented on Sep 29, 2026

cedrickchee commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions