[Linux] Codex Desktop 26.924.20706 hangs indefinitely on "Starting your task"; rollback to 26.917.71314 fixes it

What version of the Codex App are you using (From “About Codex” dialog)?

26.924.20706

What subscription do you have?

Plus

What platform is your computer?

Linux Mint, X11, amd64

What issue are you seeing?

After updating from 26.917.71314 to 26.924.20706, every local Codex task hangs indefinitely at "Starting your task".

This reproduces with both an existing project task and a brand-new trivial task.

Troubleshooting performed:

Fully exited and restarted the desktop app: no change.
Rebooted the machine: no change.
Tested with VS Code closed and only one Codex app-server running: no change.
Confirmed the app-server remains responsive to config/account/thread-list requests.
Recent logs from the failing build contain no thread/start or turn submission corresponding to the attempted task.
Logs repeatedly contain:
"ignoring invalid experimental feature enablement keys: apps_mcp_path_override"
Downgraded only the ChatGPT/Codex Desktop package from 26.924.20706 to 26.917.71314, preserving ~/.codex and all other local state.
Tasks immediately began working again.

APT history confirms:
26.917.71314 -> 26.924.20706

The older build's logs show normal thread/start and TurnInput dispatch. The failing build does not appear to dispatch the task to the app-server at all.

Expected:
Submitting a local task should create/start the thread and dispatch the user input.

Actual:
UI remains indefinitely at "Starting your task".

Workaround:
Downgrade to 26.917.71314.

This looks like a regression introduced between 26.917.71314 and 26.924.20706, possibly in the Desktop UI/app-server protocol or task-dispatch path.

What steps can reproduce the bug?

Install 26.924.20706 on Linux and try to launch a codex task

What is the expected behavior?

No response

Additional information

No response

Can confirm downgrade resolves issue on Arch Linux - #48354 (comment)

Is the new version functional for anyone on Linux? Why is there no official response on a widespread major issue after a full workday?

How is it possible to release a new version with no one even checking if it actually works ...

@okmk-code

@okmk-code @visiblehawk I confirm that this is not an issue caused by the new version. Earlier today, when the OpenAI service had problems, this issue appeared (it's not the new version). I thought waiting for the new version to be released would solve this problem. But after updating to the new version, the problem still exists.

Current Version: Version 26.924.22138
System： ubuntu 26.04

I can confirm that the latest version still isn't working. Could someone from OpenAI please get to work on this?

Current Version: Version 26.924.22138
System: Linux Mint 22.3

Whoever did the update, you triggered a self-inflicted DDoS attack on your company. Next time, have an AI test the update on multiple VMs running different operating systems at the same time.

The same problem happens on Fedora. Rolling back to 26.917.71314 solves it. That OenAI's Codex outage happened at just about the same time I upgraded was just a misleading coincidence.

@tibo-openai

2026 is the year of linux desktop (@tibo-openai) /cc @tibo-openai 😜

Same here, plus a data point on a newer build: this also happens on 26.924.22138 (desktop log build number 11645, commit 2e782921399a788a842b74ee1944a2e1e6e003a1), so that later 26.924 build did not fix it.

Linux Mint 22.3 (Zena), X11, amd64, package "chatgpt". On 26.924.22138 local Codex threads stayed on the loading spinner in my regular ~/.codex, and I could not create a new local thread there. ChatGPT chats and the web version worked throughout. Downgrading only the package to 26.917.71314 (build number 10954) fixed it and kept ~/.codex intact. A second machine on 26.917.71314 (same Mint version, same account) never had the problem.

Fresh CODEX_HOME on 26.924.22138: works but slow. thread_hydration took 10.2 to 14.6 s, runtime_resume_started only appears after 10 to 14 s while the resume itself takes about 0.1 s, turn_first_response_visible = 10301 ms. On 26.917.71314 with a fresh CODEX_HOME: 1122 ms.

Log comparison, fresh CODEX_HOME, new thread, single run each:
26.924.22138: "Failed to load shell env ... Timed out after 5000ms" at startup, "Git is unavailable" repeatedly (per thread and in the worktree archive queue).
26.917.71314: neither message appears.
I do not know whether these messages are the cause or only appear alongside the delay. /usr/bin/git 2.43.0 is installed, and a login shell without a terminal starts in about 0.2 s.

The message "ignoring invalid experimental feature enablement keys: apps_mcp_path_override" mentioned in this report also appears in my 26.924.22138 log and not in the 26.917.71314 log.

Ruled out: PRAGMA integrity_check on backup copies of thread_history_1.sqlite and state_5.sqlite returns ok, the rollout .jsonl files parse cleanly, logs_2.sqlite has WARN but no ERROR entries. Moving ~/.cache/Codex and ~/.config/Codex did not help.

Related reports from the same day: #48171 (Fedora 44 KDE, previous chats stuck loading) and #48208 (Ubuntu 24.04, thread_hydration timeout, build 11431).

Downgrade route: 26.917.71314 was no longer available from my apt sources, so I copied the .deb from another machine's /var/cache/apt/archives, installed it with apt install --allow-downgrades and pinned it with apt-mark hold chatgpt.

@okmk-code @visiblehawk I confirm that this is not an issue caused by the new version. Earlier today, when the OpenAI service had problems, this issue appeared (it's not the new version). I thought waiting for the new version to be released would solve this problem. But after updating to the new version, the problem still exists.

Current Version: Version 26.924.22138 System： ubuntu 26.04

However, rolling back to 26.917.71314 fixes the issue. It is not only the ChatGPT desktop app, the sandbox feature of Codex extension for VSCode is also not working for about a week and there is no fix unless you downgrade it as well. The fact that these new updates lacks basic tests before release is very strange.

On the outage theory: I looked for service incidents and did not find an acknowledged one for that time. On my machine the difference followed the app version, and rolling back to 26.917.71314 fixed it.

old working version package on openai server here btw, since it was removed from apt https://persistent.oaistatic.com/codex-app-prod/linux/deb/pool/main/c/chatgpt/chatgpt_26.917.71314_amd64.deb

@uwe-schwarz

Can approve that the workflow @uwe-schwarz outlined seem to work for me (Ubuntu 24.04.4 LTS, ChatGPT app version: 26.921.10847). Also, I have asked CC to execute these steps it notice that there are 7 more stuck downloads left in ~/.cache/codex-runtimes/codex-runtime-install-*

Confirmed on Fedora 44.

Following command downgrades to working version:

sudo dnf downgrade -y 'https://persistent.oaistatic.com/codex-app-prod/linux/rpm/x86_64/chatgpt-26.917.71314-1.x86_64.rpm'

Can confirm this also reproduces on the newer build 26.924.22138 (Arch Linux / Wayland, build 11645). Restarting the app does not help; every subsequent task attempt fails the same way.

Inspecting journalctl and renderer logs confirms your suspicion about why the task never gets dispatched to the local app-server:

Cloudflare Bot Challenge: During task startup, the Electron UI makes background HTTP requests to chatgpt.com (such as /ces/v1/rgstr and session endpoints). Instead of JSON, Cloudflare returns an HTML bot challenge page (<span id="challenge-error-text">Enable JavaScript and cookies to continue</span> under /cdn-cgi/challenge-platform/...).
Renderer Throws Unhandled Error: Because the app receives HTML instead of expected JSON, the renderer console logs:

[error] RequestError: Something went wrong. If this issue persists please contact us through our help center at help.openai.com.
[error] NetworkError: https://chatgpt.com/ces/v1/rgstr...

Turn Dispatch Aborts Prematurely: The UI records name=turn_first_response_visible outcome=aborted, aborting the flow before turn_input is ever sent to the local app-server. The UI stays perpetually trapped in the draft state (client-new-thread:<uuid>), showing "Starting your task".

The CLI (codex) connects directly over WebSockets and works normally, confirming the issue is isolated to the desktop Electron renderer's request handling on Linux.

I also had this problem on Linux, and I confirm that downgrading to from 26.924.22138 to 26.917.71314 fixed it.

What version of the Codex App are you using (From “About Codex” dialog)?

26.924.20706

What subscription do you have?

Plus

What platform is your computer?

Linux Mint, X11, amd64

What issue are you seeing?

After updating from 26.917.71314 to 26.924.20706, every local Codex task hangs indefinitely at "Starting your task".

This reproduces with both an existing project task and a brand-new trivial task.

Troubleshooting performed:

Fully exited and restarted the desktop app: no change.

Rebooted the machine: no change.

Tested with VS Code closed and only one Codex app-server running: no change.

Confirmed the app-server remains responsive to config/account/thread-list requests.

Recent logs from the failing build contain no thread/start or turn submission corresponding to the attempted task.

Logs repeatedly contain:
"ignoring invalid experimental feature enablement keys: apps_mcp_path_override"

Downgraded only the ChatGPT/Codex Desktop package from 26.924.20706 to 26.917.71314, preserving ~/.codex and all other local state.

Tasks immediately began working again.

APT history confirms: 26.917.71314 -> 26.924.20706

The older build's logs show normal thread/start and TurnInput dispatch. The failing build does not appear to dispatch the task to the app-server at all.

Expected: Submitting a local task should create/start the thread and dispatch the user input.

Actual: UI remains indefinitely at "Starting your task".

Workaround: Downgrade to 26.917.71314.

This looks like a regression introduced between 26.917.71314 and 26.924.20706, possibly in the Desktop UI/app-server protocol or task-dispatch path.

What steps can reproduce the bug?

Install 26.924.20706 on Linux and try to launch a codex task

What is the expected behavior?

No response

Additional information

No response

I encounter the same issue. How can OpenAI release a new version without any proper checking if it actually works ??

How can OpenAI release a new version without any proper checking if it actually works ??

May be it is a way to signal us that GPT-7 is holding them hostage.

@spiral-out-112358

Hi @spiral-out-112358

Do you already have the package 26.917.71314 .rpm x86_64 ?

Thanks a lot

I traced this further on Linux using the installed 26.924.22138 package and a cached, working 26.917.71314 package. Both were run with isolated, unsigned profiles.

Build	`SIGCHLD` registration order	Observed result
26.917.71314	Chromium’s no-op handler, then libuv’s handler	No zombie children or shell timeout
26.924.22138	libuv’s handler, then Chromium’s no-op handler 13 ms later	Zombie `bash`, `codex`, `git`, and `ps` children; shell probe timed out after 5 seconds

Inspection of the packaged startup JavaScript points to the ordering change: 26.917 enters the normal bootstrap immediately, while 26.924 adds an asynchronous preflight that probes the shell and reads startup policy before the normal bootstrap. This allows a child spawn to register libuv’s handler before Chromium’s early initialization replaces it. Chromium’s source shows the no-op registration.

As a diagnostic comparison, preserving libuv’s handler on the same 26.924 build eliminated the timeout and zombies. I also tested a modified copy that waits for Electron readiness before the preflight; it eliminated those symptoms without a signal guard. I would not recommend that JavaScript change as a user workaround: it also delays the network-policy check and possible restricted relaunch.

This strengthens the diagnosis in #48554 and #48618. An upstream fix should preserve child-exit handling while retaining the intended startup-policy ordering. My isolated tests did not include a signed-in task, so they establish the startup failure and its cause, rather than end-to-end task completion.

How is it possible to release a new version with no one even checking if it actually works ...

Is not thay they have a model that can use te computer to check....

I also encountered this issue on the newest version of Zorin OS right when the update went live, downgrading as mentioned fixed the issue.

26.924.50649 fix this case, it seems.

On Fedora this is now fixed in the latest version of the app, however running dnf update ... on its own did not see the new version yet. I simply re-downloaded the RPM from the OpenAI website and that gave me the actual latest version which includes the fix:

$ sudo dnf install ~/Desktop/chatgpt.x86_64.rpm
Updating and loading repositories:
Repositories loaded.
Package                                               Arch         Version                                                Repository                         Size
Upgrading:
 chatgpt                                              x86_64       0:26.924.50649-1                                       @commandline                    1.4 GiB
   replacing chatgpt                                  x86_64       0:26.924.22138-1                                       openai-chatgpt                  1.4 GiB

Also fixed with 26.924.50649 on linux mint.

Navigation Menu

Repository navigation

[Linux] Codex Desktop 26.924.20706 hangs indefinitely on "Starting your task"; rollback to 26.917.71314 fixes it #48189

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

9 remaining items

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Linux] Codex Desktop 26.924.20706 hangs indefinitely on "Starting your task"; rollback to 26.917.71314 fixes it #48189

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

loteque commented on Sep 26, 2026

okmk-code commented on Sep 26, 2026

visiblehawk commented on Sep 26, 2026

rain2307 commented on Sep 26, 2026

Operafluxo commented on Sep 26, 2026

RogerWiberg commented on Sep 26, 2026

bhack commented on Sep 26, 2026

RalfSei commented on Sep 26, 2026

visiblehawk commented on Sep 26, 2026

RalfSei commented on Sep 26, 2026

okmk-code commented on Sep 26, 2026

9 remaining items

costiash commented on Sep 27, 2026

Ginden commented on Sep 27, 2026

dantra13 commented on Sep 27, 2026

philip-soerensen commented on Sep 28, 2026

GenieManager422 commented on Sep 28, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Shulyaka commented on Sep 28, 2026

duggytuxy commented on Sep 28, 2026

bhack commented on Sep 28, 2026

Lombey commented on Sep 28, 2026

WillF07 commented on Sep 28, 2026

duggytuxy commented on Sep 28, 2026

hnsr commented on Sep 28, 2026

Hooplahaha commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions