Windows Desktop 26.721.4979.0 is severely laggy during startup/resume with a large local profile

Open 💬 1 comment Opened Jul 28, 2026 by coconilu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.721.4979.0 from the Microsoft Store (OpenAI.Codex_26.721.4979.0_x64)

What subscription do you have?

Not provided. The slowdown occurs during local Desktop startup/resume, before model response latency is relevant.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

  • Windows 11 Pro, build 26200
  • AMD Ryzen 9 9950X3D, 16 cores / 32 logical processors
  • 64 GB RAM
  • NVIDIA GeForce RTX 5090 D

What issue are you seeing?

Codex Desktop becomes severely laggy immediately after launching or reopening it. Initial UI interaction is noticeably delayed even though this is a high-end workstation and the machine is not short on CPU cores, RAM, or GPU capacity.

The bottleneck is not yet confirmed. A read-only inspection of the running app and local Codex profile found:

  • 9 ChatGPT.exe Desktop processes plus 1 bundled codex.exe app-server process, using about 2.0 GiB combined working set at the time of inspection.
  • In a 5-second sample after the app was already running, the two busiest ChatGPT.exe processes used about 32.8% and 23.1% of one logical core.
  • The active WmiPrvSE.exe processes used about 21.9% of one logical core in aggregate during the same sample.
  • No active git.exe or taskkill.exe process storm was observed in that sample.
  • %USERPROFILE%\.codex\logs_2.sqlite was 1,322,487,808 bytes (about 1.23 GiB) with 264,412 rows.
  • SQLite metadata reported 322,873 pages and 188,114 freelist pages, so a large portion of the diagnostic DB is allocated but currently free.
  • %USERPROFILE%\.codex\sessions contained 508 JSONL files totaling about 2.82 GiB; the largest single rollout was about 469 MiB.

These profile-size and process observations are correlations, not a claim that SQLite, session history, WMI, or the renderer is the sole root cause. The user-visible problem is that startup/resume work blocks or heavily delays the Desktop UI on hardware that should have substantial headroom.

What steps can reproduce the bug?

  1. Use Codex Desktop normally until the local profile contains a substantial amount of session history.
  2. Fully launch or reopen Codex Desktop on Windows.
  3. Immediately try to interact with the sidebar, open a conversation, or use the composer.
  4. Observe severe UI lag during the initial startup/resume period.

The issue is currently reproducible with the profile metrics listed above. Raw conversation contents, repository names, and log contents are intentionally not attached for privacy.

What is the expected behavior?

Codex Desktop should become interactive promptly on a high-end Windows workstation. Loading or reconciling local sessions, diagnostic logs, workspace metadata, and background process information should not block the renderer or make the initial UI severely laggy.

If startup work is necessarily long, the app should show bounded progress and keep navigation/input responsive.

Additional information

Related reports:

  • #20214 — general Windows 11 Desktop freezing/stuttering
  • #28109 — input freezes after opening Desktop with a large sessions directory
  • #29499 — WMI Provider Host CPU after startup
  • #27741 — launch failure when logs_2.sqlite becomes very large
  • #24275 — rapid logs_2.sqlite / WAL growth
  • #34260 — Windows WMI / taskkill.exe process storm

This report is intentionally narrower: it adds a reproduction on the current 26.721.4979.0 Store build, current high-end hardware, quantified local-profile size, and a read-only process sample without an active Git/taskkill storm.

Suggested acceptance criteria:

  • [ ] Startup/reopen diagnostics identify the time spent in renderer initialization, app-server handshake, local database maintenance, session listing/hydration, workspace scanning, and process discovery.
  • [ ] Desktop remains responsive while loading a synthetic profile containing at least 500 session files, multi-gigabyte rollout history, and a 1+ GiB diagnostic log database.
  • [ ] Diagnostic log maintenance and session reconciliation are bounded, cancellable, or deferred off the UI-critical path.
  • [ ] A regression test or trace demonstrates that startup/resume work no longer causes severe input or navigation lag on Windows.

Non-goals:

  • Model inference/network response latency.
  • Codex CLI or TUI startup performance.
  • Assuming all related Windows performance reports share one root cause.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 month ago

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

  • #35674
  • #34450

Powered by Codex Action