[Linux] Codex Desktop 26.924.x: every conversation hangs on open, thread/resume never reaches app-server #48413

Activity

1. delterfln

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 26, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 26, 2026
3. github-actions commented on Sep 26, 2026

   

   github-actionsBot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Linux Desktop] 26.924.20706 hangs loading existing chats; rollback to 26.917.71314 fixes it #48345
   • [Linux Desktop][26.924 regression] Existing threads fail to load; terminal TUI opens older threads normally #48397
   • [Linux Desktop][Regression] Codex UI hangs after update; thread_hydration times out while app-server remains responsive #48208
   • [Linux][Fedora Silverblue 44] 26.924.20706 regression: chats stuck loading, terminal unavailable, Git changes panel missing #48225
   • [Linux] Cannot open any previous chats after update, stuck on Loading #48171

   Powered by Codex Action
4. svenguiarrutti commented on Sep 26, 2026

   

   svenguiarrutti

   on Sep 26, 2026

   More actions

   Same problem here on ubuntu. Trying a rollback to solve the issue current version 26.924.22138
5. linear

   added

   Linux

   on Sep 26, 2026
6. zhhe17 commented on Sep 26, 2026

   

   zhhe17

   on Sep 26, 2026

   More actions

   Confirming on 26.924.22138 (Linux, Ubuntu 26.04, x86_64), with an A/B test on the same
   machine: 26.917.71314 loads local threads in ~350ms; both 26.924.20706 and 26.924.22138
   hang. So the regression was introduced in the 26.924 branch, not just .20706.

   Additional diagnostics:

   • Every open of a local thread logs maybe_resume_started; app-server receives
     thread/read + permissionProfile/list + config/read + plugin/installed + hooks/list,
     then nothing. thread/resume never arrives. No exception, no Sentry event, no
     timeout/retry log — a silent renderer-side stall. On the first attempt after app
     start the chain gets as far as model/list + collaborationMode/list + skills/list
     before stalling; subsequent attempts stall earlier, as if a shared init lock is held.
   • The bundled app-server binary (0.158.0-alpha.2.1) is healthy: driving it directly via
     JSONRPC, thread/read, thread/turns/list and thread/items/list all respond instantly
     with full history. Data and Rust backend are fine; the stall is in the desktop
     renderer's prepare step, before thread/resume is sent.
   • Cloud conversations are unaffected (different render path), matching other reports.

   Workaround verified: downgrade to 26.917.71314 (deb from the apt CDN pool) + hold.

   Environment note: model catalog and openai_base_url are injected by a local proxy
   (OpenCodex); config.toml was identical across the working and broken versions.
7. sin4ch commented on Sep 26, 2026

   

   sin4ch

   on Sep 26, 2026

   More actions

   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.
8. yuzhu-oai commented on Sep 28, 2026

   

   yuzhu-oai

   on Sep 28, 2026

   Contributor

   More actions

   The issue has been fixed. Please update to the latest version.
9. yuzhu-oai

   closed this as completedon Sep 28, 2026