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?
-
Use a task containing many command outputs or large diffs.
-
Request recent task history with outputs included:
{
"threadId": "<redacted-task-id>",
"hostId": "local",
"turnLimit": 10,
"includeOutputs": true,
"maxOutputCharsPerItem": 20000
}
-
Observe that hundreds of individually capped items can accumulate into one much larger minified serialized result.
-
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.
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 armWhat 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_threadreturned 806,992 serialized characters across 10 turns and 544 items;kernel_taskrose to roughly 38% CPU while macOS applied thermal mitigation;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?
Use a task containing many command outputs or large diffs.
Request recent task history with outputs included:
{ "threadId": "<redacted-task-id>", "hostId": "local", "turnLimit": 10, "includeOutputs": true, "maxOutputCharsPerItem": 20000 }Observe that hundreds of individually capped items can accumulate into one much larger minified serialized result.
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
maxOutputCharsPerItemlimits 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?
Additional information
A local mitigation was validated with these controls:
read_threadserialization at 131,072 characters and return truncation metadata;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.