Codex Desktop sidebar progressively freezes when thread title/preview metadata contains full transcripts

Summary

On Codex Desktop for Windows, the left sidebar initially works normally after
launch. After roughly 10 seconds, hover highlighting begins lagging behind the
mouse. A few seconds later, the sidebar stops responding completely.

The editor, composer, tool controls, and other task UI continue working. The
New task button also continues working. The failure is isolated to sidebar
navigation such as Scheduled, Plugins, Sites, projects, and existing tasks.

The issue was traced to oversized metadata in state_5.sqlite. Fourteen rows in
the threads table had entire transcripts stored in both title and preview.
The largest values were 52,333 characters each. Normalizing only those cached
metadata fields fixed the sidebar immediately after restarting Codex. No chat
transcripts were deleted or modified.

Environment

• OS: Windows 11 Home, build 26200
• Codex/ChatGPT package: OpenAI.Codex 26.707.3748.0
• Bundled Chromium: 150.0.7871.101
• Thread index: 210 rows
• Installation: Microsoft Store package

Steps to reproduce

1. Have one or more threads rows whose title and preview contain a very

large prompt or a complete transcript (observed range: 7,819 to 52,333
characters).

1. Start Codex Desktop.
2. Immediately move the pointer across projects and task entries in the left

sidebar.

1. Observe that hover feedback initially tracks the pointer normally.
2. Wait approximately 10 seconds while sidebar/project/task data loads.
3. Hover feedback begins falling behind the pointer and stuttering.
4. After several more seconds, sidebar links no longer respond.
5. Observe that New task and the main task interface still work.

Expected behavior

• Thread metadata should be bounded and validated before persistence.
• The sidebar should remain responsive regardless of prompt or transcript size.
• Large first messages should not be copied wholesale into user-facing title

or preview fields.

Actual behavior

• Some historical/imported threads had title, preview, and

first_user_message values of identical transcript-sized length.

• The sidebar progressively became unresponsive after loading those records.
• Reinstalling the app and restarting Windows did not help because

%USERPROFILE%\.codex\state_5.sqlite persisted.

Diagnostic evidence

The database itself passed PRAGMA integrity_check; this was a metadata-content
problem, not SQLite file corruption.

Before repair:

threads: 210
maximum title length: 52,333
maximum preview length: 52,333
rows with title or preview over 5,000 characters: 14
database integrity: ok

Representative read-only query:

SELECT
  id,
  length(title) AS title_length,
  length(preview) AS preview_length
FROM threads
WHERE length(title) > 5000 OR length(preview) > 5000
ORDER BY length(title) DESC;

The affected values included entire tool transcripts and approval-review
transcripts rather than short task titles.

Confirmed local workaround

1. Fully close Codex.
2. Back up %USERPROFILE%\.codex\state_5.sqlite using SQLite's backup API.
3. For only the 14 rows exceeding 5,000 characters:

• collapse whitespace;
• truncate title to 160 characters;
• truncate preview to 500 characters;
• leave the rollout/session transcript unchanged.

1. Run PRAGMA integrity_check.
2. Restart Codex.

Result:

rows with title over 5,000 characters: 0
rows with preview over 5,000 characters: 0
database integrity: ok
sidebar remains responsive: confirmed

Suggested product fix

1. Enforce maximum lengths when writing threads.title and threads.preview.
2. Never use a complete transcript as a title or preview fallback.
3. Add a migration/read-repair step for existing oversized metadata.
4. Truncate defensively in the app-server response as well as the desktop UI.
5. Keep the sidebar virtualized and avoid measuring/rendering unbounded strings.
6. Add a regression test with multiple 50,000-character metadata values.

Suggested conservative limits:

• title: 160-256 characters
• preview: 500-1,000 characters

Privacy note

The affected database and transcripts contain private local task content and
should not be attached publicly. The lengths, row counts, schema fields, and
sanitized reproduction details above are sufficient to demonstrate the bug.