26.707.72221 - App freezes immediate when accessing current threads. #33169

Activity

1. wilrankinen906

   added

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

   on Jul 14, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

   performance

   on Jul 14, 2026
3. github-actions commented on Jul 14, 2026

   

   github-actionsbot

   on Jul 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • App crashes when reopening a chat #32426
   • [Codex app] Opening existing local conversations stalls 10–45s in thread/resume #32068

   Powered by Codex Action
4. theophanemayaud commented on Jul 15, 2026

   

   theophanemayaud

   on Jul 15, 2026

   Last edited by theophanemayaud

   More actions

   Similar here, it's not fully/indefinitely freezing, it's just very very very slow laggy and yes temporarily freezing.

   From sol high's own investigations:

   Technical diagnosis

   This appears to be caused by the interaction of two behaviors in Desktop 26.707.72221:

   1. Resuming a task adds it to streamingConversations even when its latest turn is already completed.
   2. Task resume and desktop-client reconnect broadcast complete in-memory conversationState snapshots for those resident tasks.

   Evidence from the installed macOS bundle

   I inspected:

   /Applications/ChatGPT.app/Contents/Resources/app.asar

   The de-minified equivalent of the relevant code is:

   handleClientStatusChanged({ status }) {
     if (status === "connected") {
       for (const conversationId of this.streamingConversations) {
         this.broadcastConversationSnapshot(conversationId);
       }
     }
   }
   
   broadcastConversationSnapshot(conversationId) {
     const conversationState =
       this.threadStore.getConversation(conversationId);
   
     dispatchMessageFromView("thread-stream-state-changed", {
       conversationId,
       change: {
         type: "snapshot",
         revision,
         conversationState,
       },
     });
   }

   The task-resume path also effectively does:

   markConversationStreaming(conversationId);
   setConversationStreamRole(conversationId, { role: "owner" });
   broadcastConversationSnapshot(conversationId);

   Therefore, opening an existing task loads it into the resident streaming set and immediately broadcasts its state. A later desktop IPC reconnect broadcasts snapshots for every task retained in that set, including unrelated or completed tasks.

   The IPC size guard runs only after full serialization:

   const serialized = JSON.stringify(message);
   const payloadBytes = Buffer.byteLength(serialized, "utf8");
   
   if (payloadBytes > 268435456) {
     // Drop oversized broadcast
   }

   Consequently, even a dropped snapshot still incurs the complete object traversal, JSON allocation, and byte-counting cost. Snapshots below 256 MiB are transmitted and then parsed/reconciled by the renderer.

   Completed tasks are incorrectly retained as streaming

   The Desktop logs show completed tasks being resumed with markedStreaming=true:

   conversationId=019eb174-... latestTurnStatus=completed markedStreaming=true turnCount=198
   conversationId=019f602f-... latestTurnStatus=completed markedStreaming=true turnCount=226
   conversationId=019ebaa4-... latestTurnStatus=completed markedStreaming=true turnCount=23
   

   Another hidden task was simultaneously active:

   conversationId=019eac1a-... latestTurnStatus=inProgress markedStreaming=true turnCount=53 documentVisibilityState=hidden
   

   The corresponding local rollout files were approximately:

   63.3 MiB
   63.1 MiB
   23.5 MiB
   20.9 MiB
   6.5 MiB
   

   These are on-disk rollout sizes, not measured IPC frame sizes, but they show that several large histories are being restored into the same Desktop process.

   Runtime effect

   A live macOS sample showed:

   Codex Renderer CPU while updating: 185–232%
   Codex Renderer CPU while idle:     0%
   Renderer physical footprint peak:  2.9 GiB
   Hot path:                           Electron/V8 main thread
   

   The backend thread/resume calls themselves generally completed in approximately 0.4–1.5 seconds. The much longer perceived freeze occurs after/during snapshot processing and renderer reconciliation.

   The machine was not resource-starved:

   Memory pressure: healthy
   Swap:            zero
   Free disk:        ~180 GiB
   

   Why restarting does not fix it

   Restarting clears the process, but the Desktop immediately resumes persisted tasks and marks them streaming again. Once the large existing tasks are opened/restored, the same snapshot fan-out and renderer work recur.

   Additional Browser Use amplification

   There is also repeated Browser Use lifecycle churn in the same renderer:

   browser use open wait timed out
   renderer disposed browser sidebar webview
   renderer removed browser sidebar webview
   renderer created browser sidebar webview
   iab backend request failed
   ResizeObserver loop completed with undelivered notifications
   

   This matches #33133 and likely amplifies the renderer load, but the full-state snapshot behavior is independently present and affects ordinary existing tasks.

   Suspected required fix

   • Do not mark completed tasks as streaming during normal resume.
   • Remove completed/inactive tasks from streamingConversations.
   • On client connection, do not broadcast snapshots for every resident task.
   • Send only the currently selected task or bounded metadata.
   • Paginate/lazy-load historical turns.
   • Apply byte/count limits before constructing and serializing a complete snapshot.
   • Avoid rebuilding the whole renderer state when only incremental patches are needed.

   Related current-build report: #32722.
5. mohamedhajr commented on Jul 15, 2026

   

   mohamedhajr

   on Jul 15, 2026

   More actions

   I can reproduce this on macOS 26.5.1 (Apple Silicon) with Codex Desktop 26.707.72221 (build 5307; bundled CLI 0.144.2).

   The main renderer stayed at 99–103% CPU indefinitely. A macOS sample showed the hot path on the Electron/V8 main thread in repeated JS/JIT frames; the app-server and system memory/disk were healthy.

   Additional isolation evidence:

   • Reinstalling the signed/notarized app and resetting the Electron UI profile did not fix it while the existing CODEX_HOME state was retained.
   • An isolated empty CODEX_HOME was healthy. Auth-only, auth+config, and auth+config+state-DB controls were also healthy.
   • codex doctor passed all 17 checks.
   • The state DB had 79 thread_spawn_edges, all marked open. Several child rollouts ended with task_complete, but their spawn edges were still open; an active multi-agent parent also had children updating.
   • The persisted global state contained 23 thread-client-id-v1:* mappings, including completed/archived multi-agent parents, plus persisted per-thread browser-tab state.

   Targeted workaround: quit Codex, back up/remove only ~/.codex/.codex-global-state.json and its .bak, then relaunch. Codex regenerated a 989-byte clean state file, renderer CPU dropped immediately to 0%, and the UI remained responsive. Sessions, auth, config, skills, and repositories were preserved.

   This strongly supports the diagnosis above: stale desktop client/resume mappings retain completed subagent threads and trigger full snapshot fan-out/reconciliation in the renderer. A newly configured daily automation was ruled out because it had never executed.

   👎React with 👎1Reacted by cutexx52