macOS Desktop: app-server pins ~2 cores rebuilding thread-history pages from very large rollout JSONLs (full re-parse per page)

What version of the Codex App are you using (From "About Codex" dialog)?

26.715.72359 (build 5718). Embedded Codex Framework: 150.0.7871.124.

What platform is your computer?

Darwin 25.5.0 arm64 — macOS 26.5.2 (25F84), Mac17,8 (Apple Silicon).

What issue are you seeing?

codex … app-server sustains ~210–230% CPU and ~2.6–2.8 GB RSS indefinitely when the account has long-lived sessions whose rollout JSONL files have grown very large (in my case two active sessions at 679 MB and 582 MB, started 2026-06-03 and 2026-07-03 and still in use). The burn starts immediately after app launch and does not settle — it is a steady state, not a startup transient.

Sampled 20 s apart right after relaunching the app (pid = fresh app-server):

etime  %cpu   rss(KB)   cputime
01:06  227.7  2740480   2:22.33
01:26  223.4  2661600   3:07.43
01:46  217.0  2724720   3:52.55
02:06  215.8  2789632   4:37.73
02:26  213.9  2559440   5:16.80
02:46  210.3  2798032   6:01.03

That is ~6 minutes of CPU time consumed in the first 2m46s of process lifetime, and it continues at that rate.

Where the time goes (symbolized sample profile)

sample <pid> 3 on the busy app-server shows the hot path is thread-history page construction re-processing rollout items:

codex_app_server::request_processors::thread_processor::build_thread_turns_page_response
codex_app_server::request_processors::build_legacy_api_turns_from_rollout_items
codex_app_server_protocol::protocol::thread_history::ThreadHistoryBuilder::handle_rollout_item
codex_app_server_protocol::protocol::thread_history::ThreadHistoryBuilder::handle_event
codex_protocol::dynamic_tools::normalize_dynamic_tool_specs
codex_protocol::items::parse_hook_prompt_message

(thread_processor.rs in codex-rs/app-server/src/request_processors/.)

lsof on the app-server shows both giant rollout files open (each with two open file descriptors) the whole time. An earlier sample of the same behavior on the previous app build additionally showed heavy serde_json deserialization under tokio fs reads.

So it appears each thread/turns/list-style page request rebuilds turns by re-reading/re-parsing the rollout from the raw JSONL rather than consulting an index, which for a rollout of hundreds of MB means the same hundreds of MB are deserialized over and over. With two such sessions open this pins ~2 cores permanently and re-runs the full ingest after every app relaunch.

Likely-related fallout: recurring V8 OOM aborts

The same installation has the desktop app crashing every ~8–16 h since 2026-07-18 (7 .ips reports, spanning two macOS versions, so not OS-related). All share one signature — SIGABRT on a worker thread named git:

abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
v8::ExternalMemoryAccounter::Update(v8::Isolate*, long long)

This matches #34213, so I'm not re-reporting it as new — noting it here because on this machine the crash cadence coincides with the giant-session load described above, and each crash triggers another full rollout re-ingest on relaunch, similar to the refetch storm described in #34890. Happy to attach the .ips files here or to #34213 on request.

Steps to reproduce

1. Run a single Codex desktop session continuously for weeks so its rollout JSONL grows to hundreds of MB (mine reached ~680 MB).
2. Quit and relaunch the app with that session still active.
3. Watch the app-server process: CPU sits at ~2 cores indefinitely; sample shows the frames above.

Expected behavior

Serving a page of thread history should be roughly proportional to the page size, not to the total rollout file size — e.g. via a persisted index/offset map or cached parsed turns — and having a large-history session open should not consume multiple cores at steady state.

Related issues

• #22991 — UI freezes with very large rollout/history JSONLs (this report adds a symbolized profile of the suspected hot path)
• #34890 — renderer OOM/refetch storm dominated by thread/turns/list
• #34213 — V8 OOM in git worker thread (same crash signature as seen here)
• #24048 — app-server memory growth on large tool output