Thread navigation/loading slows from unbounded metadata and eager large-history hydration

[clairernovotny]

Supersedes #21154. The original root cause was threads.title becoming the full first user message, but the local diagnostics now point to a broader performance problem in thread navigation and thread loading:

• unbounded thread metadata can bloat the SQLite thread-list/navigation path
• a SQLite-only trim is temporary because reconciliation can repopulate titles from JSONL history
• thread/list can still be huge when first_user_message is treated as a full prompt/history field instead of a bounded preview
• opening a large thread can still be slow because the UI path eagerly hydrates/replays too much history

User impact

Codex Desktop becomes sluggish when switching chats and when opening/loading large threads. The visible UX impact is not just a database query delay: the app can appear stuck while the renderer parses, allocates, reconciles, and renders large thread payloads.

In local testing, trimming pathological titles helped chat switching a lot. Loading large threads was still slow afterward, which suggests there are at least two hot paths:

1. list/navigation metadata payload size
2. initial thread-open history hydration/rendering

Title bloat impact

I benchmarked an affected local SQLite DB backup against the same row set after shortening only pathological active titles. This isolates title length as the variable.

Active rows

DB	Active rows	Active title chars	Active first_user_message chars	Max title chars	Active titles > 120
Bad backup	134	14,610,549	14,614,033	675,773	94
Same rows after title repair	134	3,588	14,614,033	120	0
Current repaired DB	158	5,154	14,614,486	120	0

Thread-list style query

Query approximating the active thread navigation/list path that needs titles:

SELECT id, title, source, cwd, updated_at_ms
FROM threads
WHERE COALESCE(archived,0)=0
ORDER BY updated_at_ms DESC, id DESC
LIMIT 200;

Measured over 80 iterations:

DB	Rows	Result payload bytes	SQLite query median	SQLite query p95	JSON encode median
Bad backup	134	15,605,594	8.12 ms	10.30 ms	46.34 ms
Same rows after title repair	134	25,074	0.15 ms	0.19 ms	0.14 ms
Current repaired DB	158	34,343	0.17 ms	0.19 ms	0.17 ms

Impact from title repair on the same rows:

• Result payload: 15.6 MB -> 25 KB, about 622x smaller.
• SQLite read median: 8.12 ms -> 0.15 ms, about 54x faster.
• JSON encode median: 46.34 ms -> 0.14 ms, about 331x faster.

This is before Electron IPC, UI reconciliation, rendering, and any extra chat-switching work.

Full list item including preview

If the list path also includes first_user_message, the duplicated title roughly doubles the heavy payload:

SELECT id, title, first_user_message, source, cwd, updated_at_ms
FROM threads
WHERE COALESCE(archived,0)=0
ORDER BY updated_at_ms DESC, id DESC
LIMIT 200;

DB	Rows	Result payload bytes	SQLite query median	SQLite query p95	JSON encode median
Bad backup	134	31,196,414	14.70 ms	17.75 ms	90.73 ms
Same rows after title repair	134	15,615,894	7.12 ms	8.55 ms	46.22 ms
Current repaired DB	158	15,626,192	7.08 ms	8.50 ms	45.40 ms

So the title bug doubled the heavy list item payload: one copy in first_user_message, another copy in title.

Reconciliation can repopulate bad titles

SQLite is not the only source of truth. Codex can rebuild or reconcile thread metadata from rollout JSONL files and session_index.jsonl.

The local failure mode appears to be:

• the state extractor reads rollout events
• the first EventMsg::UserMessage can populate both first_user_message and fallback title
• later ThreadNameUpdated events can overwrite the title
• reconciliation/upsert writes the resulting metadata back into SQLite

That means a DB-only trim can be undone later if the underlying JSONL history has no later good ThreadNameUpdated event. In practice, the durable local repair needed both:

• trim threads.title in SQLite
• append a later thread-name update to the affected JSONL histories so reconciliation keeps the bounded title

thread/list can still be too large after title repair

Bounding titles helps, but thread/list can still pay for full prompt-sized first_user_message values when those are mapped into Thread.preview.

One local active DB snapshot after repopulation showed:

active rows: 158
active title chars: 13,980,313
active first_user_message chars: 14,614,486
active titles >120 chars: 67
active first_user_message >120 chars: 105
active first_user_message >10k chars: 74
max first_user_message: 675,773 chars

This was not only RepoPrompt. Grouped by source:

vscode rows=86 first_user_message_chars=13,981,761 max=675,773 gt120=75 gt10k=54
exec   rows=22 first_user_message_chars=627,261    max=44,430  gt120=22 gt10k=20

Direct app-server probe using /Applications/Codex.app/Contents/Resources/codex app-server:

thread/list archived=false modelProviders=[] useStateDbOnly=true  limit=20   2.56s response=4,505,704 bytes
thread/list archived=false modelProviders=[] useStateDbOnly=true  limit=100  7.95s response=14,628,806 bytes
thread/list archived=false modelProviders=[] useStateDbOnly=false limit=100  8.26s response=14,627,363 bytes

This suggests first_user_message should either be bounded as a preview field for list/read summaries, or the full field should not be selected/sent in thread/list.

Opening large threads is a separate hot path

Direct app-server timings show that metadata-only reads are fast, but full turn reads can be very expensive:

48.7 MB rollout, image-heavy:
thread/read includeTurns=false  62.8 ms     response=850 bytes
thread/read includeTurns=true   11.65 s     response=20,654,619 bytes

45.9 MB rollout, compaction-heavy:
thread/read includeTurns=false  27.8 ms     response=875 bytes
thread/read includeTurns=true   3.39 s      response=6,363,354 bytes

1.4 MB rollout with giant first user message/title/preview:
thread/read includeTurns=false  415.9 ms    response=704,374 bytes
thread/read includeTurns=true   814.0 ms    response=1,414,448 bytes

The large rollouts are not all prompt-import cases. Large contributors included image generation events, compaction payloads, function/tool outputs, MCP tool results, and exec output.

Separate CDP profiling inside Codex Desktop showed the UI layer can still be the bottleneck even when app-server calls are quick:

tested thread switch: about 13.4s to settle in the UI
direct app-server calls for comparable tested thread data: tens of ms
renderer heap spike during switch: >200 MB transient
long tasks during switch: repeated ~1.8-2.0s tasks

So the remaining thread-open UX issue appears to be renderer hydration/reconciliation/allocation, not only DB or app-server I/O.

UX requirement

The fix should keep the current user experience or improve it:

• switching to a thread should show usable content quickly
• older turns should continue loading automatically
• users should not have to click an extra "load older messages" control just to make opening a thread fast
• full history should remain available for scrollback, search, copy, and context inspection
• active assistant output and status should not be delayed behind background hydration

Suggested direction

I do not want to over-specify the implementation, but the fixes likely need to cover these areas:

• enforce a single bounded display-title invariant across all title producers and SQLite write boundaries
• make reconciliation preserve bounded titles instead of restoring the first-message fallback
• keep thread/list payloads bounded by treating previews as previews, not full prompt/history fields
• make initial thread open staged/paged: metadata plus newest visible turns first, older history loaded automatically afterward
• avoid sending heavyweight replay payloads in the initial UI load when a placeholder/expand-on-demand representation would preserve the UX
• add performance regression tests or fixtures for large titles, large previews, and large rollout histories

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Thread metadata can store full first user message as title, causing huge active titles #21154
• Codex Desktop sidebar loses chat history when thread titles contain large transcript chunks #21119

Powered by Codex Action

[clairernovotny]

Additional local measurements point to two separate hot paths beyond the original threads.title duplication.

1. thread/list is still huge when first_user_message is full prompt text

Current active DB state on the same machine:

active rows: 158
active title chars: 13,980,313
active first_user_message chars: 14,614,486
active titles >120 chars: 67
active first_user_message >120 chars: 105
active first_user_message >10k chars: 74
max first_user_message: 675,773 chars

This is not only RepoPrompt. Grouped by source, active first_user_message bytes are mostly vscode, but there are also exec rows with long previews:

vscode rows=86 first_user_message_chars=13,981,761 max=675,773 gt120=75 gt10k=54
exec   rows=22 first_user_message_chars=627,261    max=44,430  gt120=22 gt10k=20

Direct app-server probe using /Applications/Codex.app/Contents/Resources/codex app-server:

thread/list archived=false modelProviders=[] useStateDbOnly=true  limit=20   2.56s response=4,505,704 bytes
thread/list archived=false modelProviders=[] useStateDbOnly=true  limit=100  7.95s response=14,628,806 bytes
thread/list archived=false modelProviders=[] useStateDbOnly=false limit=100  8.26s response=14,627,363 bytes

So bounding title helps thread switching, but thread/list still pays for full preview text because the state DB select includes threads.first_user_message, and app-server maps it into Thread.preview.

Suggested fix: treat first_user_message as a bounded preview field in list/read summaries, or stop selecting/sending the full field in thread/list. Preserve full user content in rollout/history; do not duplicate it into the list summary payload.

2. Opening a thread can still be slow because thread/read includeTurns=true loads and serializes the full rollout history

Direct app-server timings:

48.7 MB rollout, image-heavy:
thread/read includeTurns=false  62.8 ms     response=850 bytes
thread/read includeTurns=true   11.65 s     response=20,654,619 bytes

45.9 MB rollout, compaction-heavy:
thread/read includeTurns=false  27.8 ms     response=875 bytes
thread/read includeTurns=true   3.39 s      response=6,363,354 bytes

1.4 MB rollout with giant first user message/title/preview:
thread/read includeTurns=false  415.9 ms    response=704,374 bytes
thread/read includeTurns=true   814.0 ms    response=1,414,448 bytes

The large rollouts are not all prompt-import cases. The largest active rollout contributors I saw include:

48.7 MB rollout: image_generation_end + image_generation_call ~40 MB combined
45.9 MB rollout: compacted entries ~32 MB, user/assistant messages ~10.9 MB
33.7 MB rollout: function_call_output ~14.3 MB, mcp_tool_call_end ~10.7 MB, compacted ~3.2 MB
12.5 MB rollout: function_call_output ~3.9 MB, image_generation event/call ~4.8 MB, exec_command_end ~1.6 MB

Suggested fixes:

• Make thread open lazy/page turns by default rather than returning all turns on every thread/read includeTurns=true path.
• Use thread/turns/list or a similar paginated endpoint for history hydration.
• Avoid sending heavyweight replay payloads in initial UI load: image blobs, large compaction payloads, function/tool outputs, MCP tool results, and large exec output should be placeholder/expand-on-demand data.
• Audit duplicated persistence/replay surfaces. Some data appears in both response items and event messages, e.g. image generation call/end and tool/function output/end pairs.

In short: #21154/#21211 title bounding fixes one major multiplier, but there is also a preview/list payload issue and a full-history initial-load issue.

[clairernovotny]

I put the local workaround and perf notes here: https://github.com/clairernovotny/codex-perf

It currently includes:

• CDP launcher wrappers for macOS and Windows
• runtime title repair through Codex app actions (threads.list / threads.set_title)
• click-time threads.read prefetch while native Codex thread navigation continues
• README notes tying the title payload numbers in this issue to Electron renderer lag

The Windows launcher also looks for the MSIX install shape under C:\Program Files\WindowsApps\OpenAI.Codex_*\app.

[baron]

Additional diagnostics from another affected local profile. I am intentionally omitting local paths, thread ids, cwd values, and prompt contents.

Environment/context:

• macOS arm64
• Codex Desktop 26.429.61741
• SQLite state database was 999 MB before compaction
• dbstat showed almost all space was in the threads table

Before title repair:

• active thread rows: 6,073
• active titles over 120 chars: 5,364
• active rows where title == first_user_message: 6,026
• total active title chars: 497,767,675
• max active title length: 927,895 chars
• title-list payload: 2,862,722 bytes
• title-list SQLite median: 2.078 ms, p95: 5.148 ms
• title-list JSON encode median: 17.012 ms, p95: 25.549 ms
• full list item payload including first_user_message: 5,656,533 bytes
• full list item JSON encode median: 31.474 ms, p95: 39.892 ms

After applying only title capping/repair to 120 chars:

• active titles over 120 chars: 0
• total active title chars: 462,934
• max active title length: 120 chars
• title-list payload: 97,799 bytes
• title-list SQLite median: 0.268 ms, p95: 0.312 ms
• title-list JSON encode median: 0.312 ms, p95: 0.340 ms
• full list item payload including first_user_message: 2,891,610 bytes
• full list item JSON encode median: 16.948 ms, p95: 19.274 ms
• SQLite integrity check: ok

Post-repair storage shape:

• sum(length(title)): 462,934
• sum(length(first_user_message)): 497,772,414
• max first_user_message: 927,895 chars
• after checkpoint/VACUUM, state_5.sqlite was still about 506 MB, with threads about 525,783,040 bytes, now mostly due to retained first_user_message

Follow-up proof that the hot list path still carries the full first message as preview:

• The packaged renderer code path for recent sidebar threads calls app-server method thread/list with limit, cursor, sortKey, archived: false, and local source kinds.
• I then called the real codex app-server thread/list method against a copied state DB and measured only response field names and string lengths, not contents.
• For thread/list with limit=20 after title repair, the response was 2,644,782 bytes.
• Those 20 rows included a preview field totaling 2,445,255 chars.
• Max single preview length in that response was 442,542 chars.
• Correlating the same 20 rows back to SQLite by id, length(api.preview) == length(threads.first_user_message) for 20/20 rows.
• The summed API preview length exactly matched the summed SQLite first_user_message length for those rows: 2,445,255 chars.

So title repair fixes the duplicated prompt-sized title field, but the thread/list/sidebar response still appears to transport unbounded first_user_message as preview. Even if the UI visually truncates it, the hot list path is still paying to read, serialize, transfer, parse, and retain those large previews.

Operational note: running the repair/compaction while a live Codex Desktop or CLI app-server is active is risky. In one attempt, the app-server respawned/held the DB during repair and the WAL temporarily grew to about 509 MB. The safe procedure was to run maintenance offline: fully quit/stop Codex app-server, run title repair, checkpoint/truncate WAL, then VACUUM.

This seems to support two separate fixes:

1. Do not persist prompt-sized text into threads.title; generate/store bounded titles at write time and/or repair existing state.
2. Do not return unbounded first_user_message as preview from thread/list / recent-thread sidebar APIs. Either omit it from the hot list path, return a bounded preview, or store a separate capped preview column. Even with titles fixed, large first messages still dominate the table and full-list serialization cost.

[rdylina]

Adding another macOS repro. Codex 26.506.31421, one completed local thread with an 825MB rollout: opening/resuming caused thread/resume to take 252,892ms, then desktop dropped thread-stream-state-changed because payloadBytes=405234701 exceeded maxIpcFrameBytes=268435456. app-server RSS was ~4.5-5GB. This looks like eager full-thread hydration plus full-state IPC, not just thread-list/title bloat; the fix probably needs bounded resume/read plus paged turns/items and tail-only desktop opening.