Codex App hangs/high CPU when selecting a thread with large rollout JSONL events

Summary

Selecting a large existing thread in Codex App can make the app appear unresponsive for a long time while a Codex renderer/subprocess continuously uses CPU.

Environment

• Codex App: 26.608.12217
• Codex CLI: 0.137.0-alpha.4
• macOS: 26.5.1
• Machine: Apple M1, 16GB RAM
• Surface: Codex App

What happened

When selecting an older project thread from the sidebar, Agent attach/load stayed unresponsive for a long time. Activity Monitor showed a Codex render/Codex subprocess with sustained CPU usage.

Local evidence

The affected thread had a large local rollout JSONL file under ~/.codex/sessions/....

Observed locally:

• rollout size: about 38.4 MB
• line count: 5072
• largest JSONL line sizes:
• 5,829,062 bytes
• 5,042,049 bytes
• 5,033,230 bytes
• 1,985,812 bytes
• token_count events near the tail showed cumulative total around 87M tokens and individual context around 130K tokens.
• ps showed the hot process was the Codex binary subprocess, not the app-server:
• /.../@openai/codex-darwin-arm64/.../bin/codex
• roughly 11-15% CPU during the stuck state
• logs also showed repeated:
• RunningService dropped without explicit close(). The connection will be closed asynchronously.

The large rollout contained multi-MB tool/output events, encrypted reasoning blobs, and previous backend output overflow diagnostics.

Expected behavior

Selecting a thread should remain responsive even if the stored rollout contains very large events.

Possible expected handling:

• lazy-load older rollout events
• truncate or summarize multi-MB event payloads in the UI
• virtualize rendering for long histories
• skip/defer encrypted reasoning blobs or huge tool outputs until explicitly expanded
• show a large-thread loading state with a cancel/continue option
• avoid parsing/rendering the entire JSONL synchronously on selection

Actual behavior

The app becomes effectively stuck/unresponsive when selecting the thread, and a Codex renderer/subprocess keeps consuming CPU.

Workaround

Manually archiving the thread avoided selecting/loading the heavy rollout again.

Notes

I am intentionally omitting private local project paths and full thread identifiers from this public issue, but can provide more diagnostics if there is a preferred private channel or redaction format.