Codex Desktop: large minified `read_thread` result drives sustained GPU load and laptop overheating on macOS

Open
#35,753 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
electron

Research direction

Start by reproducing the oversized read_thread request with outputs enabled, then trace the producer-side aggregate serialization and the desktop renderer's completed-content and offscreen-placeholder handling. Done means bounded valid JSON with truncation metadata, deferred rendering and bounded previews with full-copy access, plus renderer and compositor load returning to idle after the task settles.

Written by the indexing model from the issue text.

Description

app bug performance tool-calls

What version of the Codex App are you using?

26.721.41059 (build 5848; Electron 42.3.0)

What subscription do you have?

Not disclosed; the reproduction is in the desktop client runtime and does not appear account-tier-specific.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Desktop can produce a very large, single-line minified JSON result from read_thread. Processing and displaying large completed content then sustains renderer and GPU/compositor activity, causing the laptop to heat rapidly, macOS thermal mitigation to engage, and Codex to require repeated shutdowns.

In the captured case:

  • read_thread returned 806,992 serialized characters across 10 turns and 544 items;
  • its 20,000-character setting was enforced per item, but there was no aggregate response limit;
  • the Codex GPU process sustained roughly 47–55% CPU and the renderer roughly 10–31% CPU;
  • GPU and renderer memory footprints reached roughly 1.2–1.9 GB each;
  • kernel_task rose to roughly 38% CPU while macOS applied thermal mitigation;
  • process samples were dominated by Metal/AGX, VizCompositorThread, CVDisplayLink, and compositor work.

This is a performance/local-availability bug, not a security report. No personal prompts, task contents, or private logs are attached.

What steps can reproduce the bug?

  1. Use a task containing many command outputs or large diffs.

  2. Request recent task history with outputs included:

    {
      "threadId": "<redacted-task-id>",
      "hostId": "local",
      "turnLimit": 10,
      "includeOutputs": true,
      "maxOutputCharsPerItem": 20000
    }
    
  3. Observe that hundreds of individually capped items can accumulate into one much larger minified serialized result.

  4. Keep the affected task open and observe sustained renderer/GPU compositor load, increasing memory use, heat, and thermal throttling.

The producer-side defect is that maxOutputCharsPerItem limits each item but does not limit the aggregate serialized response. The display side compounds the problem by immediately rendering completed fenced content and allowing offscreen placeholders to contain the full pathological string.

What is the expected behavior?

  • Built-in tool results should have a hard aggregate serialized-size limit.
  • Truncation should preserve valid JSON and report what was omitted.
  • Completed fenced blocks should use viewport-deferred rendering.
  • Offscreen placeholders should contain only a bounded preview.
  • Very large minified content should expose a small preview while retaining a deliberate way to copy the full value.
  • After the task settles, renderer and compositor CPU should return to idle instead of continuing to heat the laptop.

Additional information

A local mitigation was validated with these controls:

  • cap aggregate read_thread serialization at 131,072 characters and return truncation metadata;
  • defer completed code-block rendering;
  • for minified content over 128 KiB, render at most an 8,192-character preview and provide a separate full-copy action;
  • cap offscreen placeholder content at 8,192 characters.

The same captured result was reduced from 806,992 to 114,758 characters while remaining valid JSON. A synthetic 16.1-million-character fixture was reduced to 121,031 characters. Small-result behavior remained unchanged, and the patched desktop bundle passed syntax, archive-integrity, and isolated startup checks.

Possibly related to #20435, but that report is centered on MCP-server activity. This report adds a deterministic oversized-result trigger, identifies both the producer and rendering paths, and documents the associated laptop overheating and thermal throttling.

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.