26.707.72221 - App freezes immediate when accessing current threads.

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

• #32426
• #32068

Powered by Codex Action

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.

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.