Codex Desktop Renderer hangs at 100% CPU after adding a long cloud chat with interactive editor outputs to a local task

[Sanczzg]

Codex Desktop version

• Codex Desktop: 26.721.31836 build 5828
• Embedded CLI identifier: 0.146.0-alpha.3.1

Environment

• macOS Tahoe 26.5.1
• MacBook Pro 16-inch
• Apple M5 Pro
• 18-core CPU
• 20-core GPU
• 48 GB unified memory
• ChatGPT Pro subscription (20x usage tier)

Summary

Codex Desktop becomes completely unresponsive after I add an existing long cloud chat as context to a new local Codex task.

The source cloud chat contains more than 30 user/assistant exchanges and a large amount of text. It contains no images or other media, but some responses include interactive editor outputs.

The cloud chat itself opens and scrolls normally in both ChatGPT Web and the desktop client. The freeze occurs only after using the Codex Desktop feature that adds the cloud chat as context to a local Codex task through the “Add files and more” menu.

When the problem occurs, Codex (Renderer) remains at approximately 100% CPU in Activity Monitor. The backend turn continues independently and eventually completes, but reopening the affected local task reliably freezes the Renderer again.

This happened on my first attempt to use the cloud-chat-as-context feature.

Steps to reproduce

1. Open Codex Desktop and create or open a local project.
2. Start a new local Codex task intended to act as the project’s controller thread.
3. Open the composer’s “Add files and more” menu.
4. Select an existing cloud chat as context.
   • The cloud chat contains more than 30 user/assistant exchanges.
   • It contains a large amount of text.
   • It contains no images or other media.
   • Some responses contain interactive editor outputs.
   • The same cloud chat opens normally in ChatGPT Web and the desktop client.
5. Add an additional prompt to the new local Codex task.
6. Submit the prompt.
7. Observe that the entire Codex page becomes unresponsive.
8. Open macOS Activity Monitor.
9. Observe that Codex (Renderer) remains at approximately 100% CPU.
10. Wait for an extended period; the UI does not recover.
11. Force-quit and restart Codex Desktop.
12. In the sidebar, observe that the submitted turn ran for approximately 32 minutes and is marked as completed.
13. Click the affected local task.
14. Observe that Codex Desktop freezes again and Codex (Renderer) returns to approximately 100% CPU.

Expected behavior

Codex Desktop should:

• import or reference the selected cloud chat without blocking the Renderer;
• preserve supported interactive editor content without eagerly rendering an unbounded representation;
• load large chat context progressively or lazily;
• keep the UI responsive while context is processed;
• allow the resulting local task to be reopened after its turn completes;
• show a clear size or compatibility warning if a cloud chat cannot be imported safely.

Actual behavior

• The entire Codex page becomes unresponsive.
• Codex (Renderer) remains at approximately 100% CPU.
• Waiting does not restore responsiveness.
• The backend turn continues and eventually completes.
• Restarting Codex restores the rest of the application.
• Opening the affected task deterministically triggers the freeze again.
• The affected local task is effectively inaccessible through the Desktop UI.

Important distinction

This is not simply a long conversation gradually becoming slow.

The source cloud chat remains fully usable on its original Web and desktop surfaces. The problem begins only after that chat is added as context to a new local Codex task.

The resulting task appears to persist the trigger because merely reopening it after restarting Codex reproduces the freeze without submitting another prompt.

The source chat contains no images. It consists primarily of long text responses, including some interactive editor outputs. Those editor outputs may have a structured representation beyond their visible text, which could be relevant to the import, serialization, attachment-preview, hydration, or rendering path.

The fact that the backend turn completes while the Renderer is frozen suggests that the execution layer remains functional and the failure is primarily associated with the Desktop UI.

Reproducibility

• Initial cloud-chat import and submission: reproduced on the first attempt.
• Reopening the affected local task after restarting Codex: reproduced repeatedly.
• Opening the original cloud chat on Web/Desktop: works normally.
• Additional cloud-chat imports have not been attempted to avoid creating more inaccessible tasks.

Possible areas to investigate

These are hypotheses, not confirmed root causes:

• The cloud chat may be converted into one very large local user message or transcript block.
• Imported content may be duplicated across multiple event representations.
• Interactive editor outputs may be serialized into large or unsupported structured context objects.
• The attachment preview or transcript may eagerly hydrate interactive editor state.
• Long text or structured editor blocks may trigger repeated Markdown rendering, layout, reconciliation, indexing, or garbage collection.
• The affected task may lack virtualization or bounded incremental rendering when reopened.
• Cloud Chat and local Codex tasks may use different rendering paths for the same interactive editor output.

Related issues

The following reports have overlapping symptoms, but none uses the same cloud-chat import trigger:

• Codex App becomes choppy when session history contains a large user message #22283 — Large user message in session history makes Codex App choppy
  Codex App becomes choppy when session history contains a large user message #22283

• Desktop performance collapses in profiles with a few very large local conversation histories (typing, scrolling, thread list, random exits) #18693 — Desktop performance collapses with a few very large local conversation histories
  Desktop performance collapses in profiles with a few very large local conversation histories (typing, scrolling, thread list, random exits) #18693

• Codex App 26.429.61741 causes persistent high CPU usage in renderer and severe UI lag on macOS #21326 — Renderer remains at 100%–170% CPU on macOS
  Codex App 26.429.61741 causes persistent high CPU usage in renderer and severe UI lag on macOS #21326

• Codex Desktop freezes when opening mini/popout windows; image-heavy histories are much worse than long text-heavy sessions #20544 — Desktop freezes when opening content-heavy histories
  Codex Desktop freezes when opening mini/popout windows; image-heavy histories are much worse than long text-heavy sessions #20544

• Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart #24287 — Backend continues executing while Desktop UI state is frozen
  Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart #24287

• Codex Desktop becomes slow or stuck after context compaction and approval transcript injection #25009 — Desktop becomes slow or stuck after large transcript injection
  Codex Desktop becomes slow or stuck after context compaction and approval transcript injection #25009

This report is specifically about the supported product flow that adds an existing cloud chat—including interactive editor outputs—as context to a new local Codex task.

Privacy and diagnostics

I have not attached the original cloud-chat transcript because it contains private project context.

I have also not:

• opened or copied private Codex session databases;
• shared local logs;
• modified local session records;
• attached credentials, project files, commands, or private paths;
• attempted to edit the affected task’s stored data.

I can provide additional non-sensitive diagnostics if the maintainers specify exactly what is needed. A redacted process sample, affected task identifier, approximate context size, or official diagnostic bundle could be supplied privately through a documented collection process.

[paulostergaard]

Corroboration on current macOS build — very large local history triggers renderer lock

Environment

• ChatGPT/Codex Desktop 26.901.22334, build 7746
• Apple Silicon macOS
• Incident: 4 September 2026, approximately 13:08 AWST / 05:08 UTC

Opening one unusually large local Codex thread caused the UI to become non-interactive while Codex (Renderer) remained at 100–103% CPU.

The affected thread's local event history is approximately 2.3 GB / 160,932 JSONL records. During the trigger, the desktop made 308 thread/items/list calls and 46 thread/turns/list calls for that single thread over approximately 17.2 seconds.

A four-second process sample placed all 1,851 CrRendererMain samples inside V8/JIT JavaScript execution, consistent with continuous synchronous renderer work. Meanwhile:

• the bundled app-server remained responsive and initialized in 69 ms;
• state_5.sqlite and logs_2.sqlite both passed PRAGMA quick_check;
• system memory pressure and disk capacity were healthy;
• no crash report or Gatekeeper/signature failure occurred.

Terminating only the stuck renderer caused Electron to recreate it. CPU fell to approximately 11–16%, RSS fell from roughly 1.36 GB to 649 MB, and no further large-thread hydration calls were observed. No user data was deleted or reset. I have avoided deliberately reopening that thread after recovery.

This appears consistent with unbounded/eager history hydration followed by synchronous renderer processing. Expected behaviour would be paginated or lazy history loading that cannot block the UI.

I can provide a sanitized process sample and narrow log excerpts privately. I have intentionally omitted the raw rollout, prompts, credentials, repository contents, local paths, and session identifiers.