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.
Summary
The
codex app-serverloads and deserializes every session file in full on everythread/listrequest. After a few months of normal use, this becomes catastrophically slow and burns through API tokens invisibly in the background.Environment
openai.chatgptv26.422.71525 (VS Code Remote)What happens
Every time the Codex sidebar opens (or VS Code reconnects to the extension host), the app-server receives a
thread/listJSON-RPC call. In response it reads and fully deserializes every.jsonlsession file from~/.codex/sessions/. I can see this clearly in the SQLite debug log:This repeats for every session file on startup.
Observed symptoms
codex app-serverprocess running at 23–26% CPU continuously — even when idlelogs_2.sqliteandstate_5.sqlite(WAL file growing to 4MB+)Error: Channel has been closedafter 15–60 minutes — the socket to the app-server drops under loadexthost1→exthost2→exthost3...) — 5 restarts in one sessionRoot cause
The
thread/listhandler 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.