Repository navigation
[Linux Desktop][26.924 regression] Existing threads fail to load; terminal TUI opens older threads normally #48397
Description
What version of the Codex App are you using?
Current installed Linux desktop package: 26.924.22138-1 (chatgpt-desktop).
The regression started immediately after updating to 26.924.20706 on September 25, 2026. The previous installed version worked; its exact version was not recorded.
Updating again to 26.924.22138 on September 26 did not resolve it.
Bundled runtime verified with /usr/lib/chatgpt/resources/codex --version: codex-cli 0.158.0-alpha.2.1.
Desktop log build number: 11645.
Desktop build commit: 2e782921399a788a842b74ee1944a2e1e6e003a1.
What subscription do you have?
Not included in this report for privacy.
What platform is your computer?
Manjaro Linux (Arch-based), x86_64. Linux desktop app installed through the chatgpt-desktop package.
What issue are you seeing?
The desktop app launches, but existing local project threads/sessions do not finish loading. New desktop sessions appear to work.
The Codex terminal TUI can open older threads normally on the same machine. The affected user has directly tested this, so the observed failure is specific to the desktop app rather than a general inability to access older sessions.
Sanitized excerpts from the desktop logs on September 26:
maybe_resume_started hostId=local previousResumeState=needs_resume vmEvent=thread_resume_requested
response_routed durationMs=1 errorCode=null method=thread/read
name=thread_navigation outcome=failure reason=timeout durationMs=30000.3 threadKind=local threadState=cold
name=thread_navigation outcome=failure reason=timeout durationMs=30000.2 threadKind=local threadState=cold
name=thread_hydration outcome=failure reason=timeout durationMs=120000.2 marksMs={"writable_roots_ready":26.5,"metadata_ready":34.2} startupResume=false
Other old-thread read responses also complete in approximately 1–2 ms with errorCode=null, while desktop navigation/history loading stalls.
What steps can reproduce the bug?
- Launch the affected Linux desktop version with existing local project sessions.
- Select an older project thread/session.
- Observe that it remains loading and does not become interactive.
- Compare with opening an older thread in the terminal TUI on the same machine: it opens normally.
- Updating from
26.924.20706to26.924.22138does not resolve the desktop failure.
What is the expected behavior?
Existing local threads should load and become interactive in the desktop app, as they did before this update and still do in the terminal TUI.
Additional information
Closely related: #48208, which reports a Linux desktop regression after an update, successful backend requests, and thread hydration timeouts on Ubuntu. This report supplies evidence from Manjaro and a confirmed terminal-TUI comparison; a shared root cause has not been established.
Additional startup messages include a shell-environment load timeout after 5000 ms and Git is unavailable in recommended-skills/worktree-archive handling. Host Git is present at /usr/bin/git and reports version 2.55.0. Whether these warnings contribute to the history-loading failure is unknown.
The logs also contain an unsupported apps_mcp_path_override warning propagated as a connection error despite state=connected. This warning predates the current regression (see #40412), so it is not presented as the established cause.
No raw log attachments are included. Usernames, personal filesystem paths, conversation/session IDs, request IDs, account identifiers, authentication information, and conversation content have been omitted.
Activity
github-actions commentedon Sep 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
111blackeagle111 commentedon Sep 26, 2026
I can reproduce the existing local-project history failure with the official OpenAI Linux
.debon KDE neon User Edition (Ubuntu 24.04 base), x86_64, Wayland.26.917.71314→26.924.22138on September 26, 2026. Existing Codex project history stopped loading, while a new Codex chat worked.thread/listresponses completed witherrorCode=null; the local state and thread-history SQLite databases passedPRAGMA quick_check.project_id. The legacythread-project-assignmentsmap still had 41 entries, all referring to existing threads and mapped projects. The project migration marker hadprojectsMigrated=true,threadAssignmentsMigrated=false, and 25 pending thread-assignment IDs. This may be related to the missing project history; I have not established causation.26.917.71314and fully restarting the desktop app restored the project history. No local database repair or profile reset was performed.velusamy-krishnan commentedon Sep 26, 2026
I am facing same issue
shin4 commentedon Sep 27, 2026
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/readsucceeded, butthread_hydrationtimed out. Bash/Git children remained zombies after exiting; tracing showed SIGCHLD received without the affected child being reaped. Logs also showed shell-env timeouts andGit 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.
alexbic commentedon Sep 28, 2026
Confirmed on Arch/Omarchy Linux with
openai-codex-desktop 26.924.22138-1after the system update from26.915.31945-1.Existing local sessions appeared in the sidebar but many remained on the loading spinner. The web version worked, and the Codex terminal client could still open sessions. The local app-server responded to metadata and
thread/readrequests, but the Desktop UI did not finish hydrating the selected conversation.Downgrading only the Desktop package back to
26.915.31945-1immediately restored session loading; no history deletion, database repair, or login reset was needed. This reproduces the regression described here.yuzhu-oai commentedon Sep 28, 2026
The issue has been fixed. Please update to the latest version.