app-server loads ALL session files on every thread/list call — causes high CPU, slow startup, and background token waste

Summary

The codex app-server loads and deserializes every session file in full on every thread/list request. After a few months of normal use, this becomes catastrophically slow and burns through API tokens invisibly in the background.

Environment

• Extension: openai.chatgpt v26.422.71525 (VS Code Remote)
• OS: Linux (Ubuntu), VS Code Remote SSH
• Sessions accumulated: ~34 files, 624 MB total

What happens

Every time the Codex sidebar opens (or VS Code reconnects to the extension host), the app-server receives a thread/list JSON-RPC call. In response it reads and fully deserializes every .jsonl session file from ~/.codex/sessions/. I can see this clearly in the SQLite debug log:

Resuming rollout from "~/.codex/sessions/2026/03/22/rollout-...jsonl"
Resumed rollout with 9116 items, thread ID: ...

Resuming rollout from "~/.codex/sessions/2026/04/01/rollout-...jsonl"
Resumed rollout with 13819 items, thread ID: ...

This repeats for every session file on startup.

Observed symptoms

• codex app-server process running at 23–26% CPU continuously — even when idle
• Constant writes to logs_2.sqlite and state_5.sqlite (WAL file growing to 4MB+)
• VS Code extension crashes with Error: Channel has been closed after 15–60 minutes — the socket to the app-server drops under load
• Extension host restarts (exthost1 → exthost2 → exthost3...) — 5 restarts in one session
• API tokens consumed in the background with no user interaction — 75% of daily limit burned in ~50 minutes
• Slow startup that gets worse the more sessions you accumulate

Root cause

The thread/list handler appears to eagerly load full rollout data for every session to build the list, instead of reading only the metadata needed for display (title, date, model).

Fix

Load only metadata (first/last message, timestamp, thread ID) for the session list. Deserialize the full rollout only when a specific thread is opened by the user. This is standard lazy-loading — the list view doesn't need 13,000 items of conversation history per entry.

Workaround

Manually delete old session files from ~/.codex/sessions/. Keeping only 2–3 recent sessions brought CPU from ~25% to near 0% and eliminated the crashes.

Impact

This is a silent token-burning bug. Users see their daily API limit disappear with no visible activity, and have no way to know why. On limited plans or tight budgets, this is a serious problem.