Codex Windows app freezes for several seconds when opening any history conversation #33230

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

OpenAI.Codex_26.707.9981.0 (Windows package observed; About dialog version not separately available)

What subscription do you have?

Unknown / not relevant to local performance issue

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When I click any historical conversation in the Codex Windows app, Codex becomes unresponsive for several seconds. During the stall, the whole Windows desktop/mouse becomes choppy, like very low FPS. After the conversation finishes loading, the system returns to normal.

This happens regardless of whether the selected conversation is small or very large, so it looks like the app may be refreshing/scanning/parsing the local history/log store when any history item is opened.

Local diagnostics I collected:

• %USERPROFILE%\.codex\sessions contains 41 .jsonl files totaling about 951 MB.
• Largest local session files are approximately: 260 MB, 111 MB, 108 MB, 102 MB, 100 MB.
• %USERPROFILE%\.codex\logs_2.sqlite is about 221 MB.
• logs_2.sqlite-wal was around 4.7-4.9 MB and actively changing.
• Read-only SQLite inspection showed high TRACE volume:
  • Last 60 seconds: TRACE 1040 rows, estimated 3.8 MB.
  • Last 300 seconds: TRACE 2069 rows, estimated 10.7 MB.
  • Last 24 hours: TRACE 8047 rows.
• Recent top TRACE targets included:
  • codex_api::sse::responses
  • codex_app_server::outgoing_message
  • codex_mcp::connection_manager
  • codex_http_client::transport
• Several recent codex_http_client::transport TRACE rows were unusually large, around 700 KB+ each.
• During a 60-second sampling window while reproducing the issue, short CPU spikes were mainly in Codex app processes (ChatGPT.exe renderer/main processes and codex.exe), not sustained 100% disk or CPU.
• Windows Event Viewer did not show obvious recent Codex/ChatGPT/WebView AppHang/crash records. System logs did not show disk/NTFS/GPU-driver errors.
• RUST_LOG was set to warn, so the TRACE logs do not appear to be caused by my shell environment intentionally enabling trace logging.

I already submitted feedback from inside Codex with logs attached, but I am also filing this GitHub issue because the behavior is persistent and reproducible.

What steps can reproduce the bug?

1. Use Codex Windows app for a while until local history/log files become large.
2. In the Codex Windows app, open the history/conversation list.
3. Click any historical conversation. This reproduces even when the selected conversation itself is small.
4. Observe that Codex freezes for several seconds and the Windows mouse/desktop becomes choppy.
5. After the conversation finishes loading, the system returns to normal.

My current local state when reproduced:

• %USERPROFILE%\.codex\sessions: about 951 MB total JSONL history.
• %USERPROFILE%\.codex\logs_2.sqlite: about 221 MB.
• logs_2.sqlite was writing high-volume TRACE logs during the investigation.

Possible root cause: history navigation may synchronously scan/parse the local history directory and/or write high-volume TRACE logs on the UI-critical path.

What is the expected behavior?

Opening a historical conversation should not block the UI thread or make the Windows desktop/mouse choppy. The app should lazily load large transcripts, avoid full-history parsing on every history click, and avoid high-volume TRACE logging in normal production builds or keep it off the UI-critical path.

Additional information

This does not look like a hardware failure on my machine: Task Manager does not show sustained 100% disk/CPU, Event Viewer did not show Codex/WebView crashes or disk/GPU errors, and NTFS health events were normal. The issue appears as short UI/process spikes while Codex switches history conversations.

Possibly related to #21134, but this report is specifically about clicking/opening any history conversation, including small conversations, after the local session/log stores have grown large.