Codex Desktop 26.818.41509: task titles remain visible but conversations render blank until Session Storage reset #40322

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Aug 24, 2026
2. github-actions commented on Aug 24, 2026

   

   github-actionsBot

   on Aug 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Existing session fails to load, and tasks in both new and existing sessions eventually time out #40183

   Powered by Codex Action
3. hydrantkatcher commented on Sep 4, 2026

   

   hydrantkatcher

   on Sep 4, 2026

   More actions

   I am seeing the same failure on a Mac mini. Existing Codex task titles and project metadata remain visible in the sidebar, but selecting most affected tasks opens a blank pane with the logo and an empty composer. Regular ChatGPT conversations still render, and the same Codex task history remains accessible remotely from the phone, so the task data does not appear to be lost.

   Environment:

   • macOS 27.0 (build 26A5425a)
   • ChatGPT desktop 26.901.31953
   • Bundled codex-cli 0.153.1

   Tried without success:

   • Quit and reopened the app
   • Signed out and back in
   • Opened affected tasks in a new window
   • Navigated away and back

   The issue affects multiple unrelated Codex tasks rather than one project folder. Feedback diagnostics were submitted under ID: no-active-thread-01a06de5-8541-77f1-91e6-68412a673722. The feedback command inside an affected blank task also appeared to hang; submission succeeded from a regular ChatGPT conversation instead.
4. hydrantkatcher commented on Sep 4, 2026

   

   hydrantkatcher

   on Sep 4, 2026

   More actions

   Follow-up after attempting the recovery described above on ChatGPT desktop 26.901.31953 / macOS 27.0:

   1. Fully quit the app, moved ~/Library/Application Support/Codex/Default/Session Storage to a timestamped backup, reopened, and tested an affected task. The title remained visible but the conversation pane was still blank.
   2. Pressing Command-R on the affected task did not help.
   3. Fully quit again, moved the entire ~/Library/Application Support/Codex/Default profile to a timestamped backup, reopened with a clean profile, signed back in, and tested again. The sidebar title returned, but the conversation pane remained blank.

   Both original folders were preserved, and ~/.codex plus all project files were left untouched. This indicates the Session Storage recovery that worked on 26.818.41509 does not resolve the same visible symptom on 26.901.31953. The task history remains accessible through Remote on the phone.
5. sachah commented on Sep 16, 2026

   

   sachah

   on Sep 16, 2026

   More actions

   Corroborating this with a task-specific occurrence on a newer macOS build. Full logs and thread content are omitted because they contain private project information.

   Environment:

   • Codex app 26.908.70816 (build 9275; embedded framework 152.0.7977.83)
   • macOS 27.0 (26A428), Apple Silicon
   • Long-running local project task

   Observed behavior on 2026-09-16:

   • One task suddenly displayed no prior chat history, and new agent replies did not appear in its UI.
   • Other tasks remained responsive and continued rendering normally; this was not a whole-app freeze.
   • Quitting and reopening Codex at approximately 12:50 PDT restored the affected task's history and replies immediately.
   • The app/server's authoritative thread reader now returns the missing turns and agent messages, confirming the conversation data was never deleted.
   • Before restart, desktop logs show the affected task continuing to deliver reasoning/message events to electron-message-handler while its window was visible and focused.
   • During the failure window, the renderer repeatedly toggled that task's thread_stream_view_activity_changed state and attempted maybe_resume_started even though the task already reported resumeState=resumed and streamRole=owner.
   • At 12:29 PDT, the renderer issued 38 thread/items/list and 7 thread/turns/list requests for this one task in about one minute. Responses completed successfully with targetDestroyed=false, but the conversation still did not render.

   This looks like task-view hydration / stream-subscription state becoming desynchronized in one renderer, rather than missing rollout data, app-server failure, or authentication failure. Relaunching rebuilt the renderer state and recovered the view.

   Expected behavior:

   1. A successful thread/items/list / thread/turns/list response should hydrate the task view once rather than trigger a request burst.
   2. If the task view detects inconsistent stream ownership or hydration state, it should reset that task view without requiring a full app restart.
   3. The UI should distinguish a recoverable rendering failure from actual missing conversation data.
6. sachah commented on Sep 16, 2026

   

   sachah

   on Sep 16, 2026

   More actions

   Second occurrence today, captured live before restarting the app. This one provides a likely window/stream ownership trigger.

   Environment:

   • Codex desktop 26.908.70816 (build 9275)
   • macOS 27.0 (26A428), Apple Silicon
   • Chromium/Codex Framework 152.0.7977.83

   Observed behavior:

   • One task stopped displaying its recent history/replies in the primary Codex window; other tasks remained usable.
   • The app itself remained running, so process samples and logs were captured before recovery.
   • An authoritative thread/read + thread/turns/list read showed the task intact with 10 turns. The two latest turns were completed; the latest completed in about 4 seconds and contained a normal final answer. This rules out data loss and model/agent failure.

   Important log correlation:

   • The affected task had originally been created from realtime voice. Its hidden avatarOverlay renderer (WebContentsId=3, rendererWindowVisible=false) held the stream owner role.
   • When the task was opened in the visible primary window (WebContentsId=1), that window repeatedly became role=follower.
   • User turns at 22:06:10Z and 22:07:58Z were started successfully by the hidden avatarOverlay, not the visible primary renderer.
   • Before each turn/start, the overlay attempted turn/steer or turn/interrupt and received -32600 / no active turn; it then started a new turn successfully.
   • The visible primary view received successful thread/read responses but did not render the stored conversation/replies.
   • The primary renderer also logged ResizeObserver loop completed with undelivered notifications repeatedly during the affected window.

   Live process evidence:

   • Main process sample: responsive/waiting normally; physical footprint about 395 MB.
   • App-server sample: active, about 735 MB during capture.
   • Primary renderer sample: active (roughly 10–16% CPU), about 690–780 MB RSS/footprint.
   • A second renderer associated with the voice/browser surface had a roughly 2.1 GB physical footprint.
   • System memory still had about 51% free, so this was not system-wide memory exhaustion.
   • Samples did not show a native deadlock; the evidence points to renderer hydration/stream routing between the hidden voice overlay and visible primary task view.

   No restart or Session Storage reset had been performed when this evidence was collected. Private task text, IDs, filesystem paths, raw logs, and raw samples are omitted, but I can provide a sanitized excerpt if a maintainer requests it.
7. Daniel-Popov-allwyn commented on Sep 18, 2026

   

   Daniel-Popov-allwyn

   on Sep 18, 2026

   More actions

   Corroborating this with a task-specific occurrence on Windows. No task name, task ID, filesystem path, or conversation content is included.

   Environment:

   • Windows 11 Pro 25H2, build 26200.9457, x64
   • Codex app package: 26.915.3509.0
   • Bundled backend: codex-cli 0.155.0-alpha.9

   Observed sequence on September 18, 2026:

   1. One task was active when message submission failed with Codex app-server process is not available.
   2. That task remained visibly active but made no progress for about 15 minutes.
   3. After restarting Codex, the affected task title remained present, but its saved history and agent responses would not render.
   4. Other tasks continued to open and display their histories normally.
   5. A read-only check through Codex's native task index still found the affected task, and the authoritative task reader returned its retained turns, recent agent responses, and final answer. This confirms the task data is intact and the failure is in task-view hydration/rendering.
   6. A normal app restart did not restore the affected task view.

   Expected behavior: after an app-server failure or restart, each task view should rebuild from the intact authoritative history. A task-specific hydration failure should offer a safe retry/rebuild action rather than show an empty conversation indefinitely.