[Windows/WSL] Desktop update leaves thread assignments on legacy project IDs and repeatedly reloads large rollouts

Open 💬 2 comments Opened Jul 17, 2026 by PrinnyQ

Component

Codex Desktop on Windows using the WSL app-server runtime

Version

  • Windows Codex Desktop: 26.715.2305.0
  • Bundled WSL Codex runtime: 0.145.0-alpha.18
  • Platform: Windows + WSL2

Summary

After the Desktop update, existing projects were migrated to new local-<hash> project IDs, but existing thread-project-assignments were not remapped. Most project chat histories disappeared from the sidebar even though the SQLite thread rows and rollout files remained intact. A WSL-native project still showed history through path inference, and pinned threads remained visible, which made this look like selective data loss.

Opening one older, large thread also caused the app to repeatedly re-read and parse the full rollout every few seconds, effectively freezing the UI.

Deterministic local evidence

The migration ran when the updated app first opened:

  • Six entries were created in local-projects, all with new local-... IDs.
  • thread-project-assignments contained 35 existing assignments.
  • 0 of 35 assignment projectId values matched any new local-projects key.
  • All 35 still used legacy path-based IDs such as /mnt/d/.../project or /mnt/o/.../project.
  • project-order mixed new local-... IDs with a stale raw Windows path and omitted one otherwise-valid new project ID.
  • The state DB still contained 261 threads. All 259 rollouts referenced on the Windows side existed (about 3.8 GiB total); PRAGMA quick_check returned ok.

Observed UI behavior matched the broken metadata exactly:

  • A WSL-native project could infer its threads and still showed history.
  • Pinned legacy threads were still visible.
  • Other projects existed but appeared to have no chat history.

Large-thread reload loop

One affected thread had:

  • 32,398,488-byte JSONL rollout
  • 14,081 valid records, 0 parse errors
  • 176 user-message events
  • 23 compactions
  • tokens_used = 290247780

Opening it generated 66 recorder messages for thread/turns/list over 123 seconds: repeated pairs of:

Resuming rollout from "/mnt/c/Users/<user>/.codex/sessions/...jsonl"
Resumed rollout with 14081 items ... parse errors: 0

This corresponds to roughly 33 complete reloads of the same 32.4 MB rollout. The request loop continued every few seconds even though the file parsed successfully.

The logs also contained repeated warnings:

state db codex_home mismatch:
expected /home/<user>/.codex/sqlite,
got /mnt/c/Users/<user>/.codex

There were 280 such warnings in the DB, including 78 in a recent 15-minute interval. The Desktop-launched WSL command explicitly sets:

CODEX_SQLITE_HOME="$HOME/.codex/sqlite" ... codex app-server

Steps to reproduce

  1. Use Codex Desktop on Windows with WSL runtime and multiple existing projects/threads.
  2. Have legacy path-based values in thread-project-assignments.
  3. Upgrade to the version above and restart Desktop.
  4. Observe that local-projects is rebuilt with hashed IDs but thread assignments retain path IDs.
  5. Open the sidebar: most project histories are missing, while path-inferred or pinned threads may remain visible.
  6. Open an older large thread stored under the Windows-side Codex home.
  7. Observe repeated thread/turns/list full-rollout parsing and UI stalls.

Expected behavior

  • Project migration should atomically remap every legacy assignment to the new local-... project ID.
  • project-order, selected/pinned project metadata, and thread assignments should use the same ID namespace.
  • A successful thread/turns/list should not trigger an unbounded full-rollout reload loop.
  • Split SQLite/session homes in the supported Windows+WSL launcher configuration should not emit repeated mismatch warnings or cause thread visibility problems.
  • Updates should provide a safe re-index/recovery path.

Actual behavior

Project records are migrated but their thread assignments are left behind in the old namespace. Histories become invisible without data loss. Large Windows-side rollouts may then be parsed repeatedly, causing severe UI stalls.

Recovery being tested locally

With timestamped backups:

  1. Remap legacy assignment IDs to the corresponding new local-... IDs and repair project ordering.
  2. Move the problematic rollout to WSL-local storage and update its SQLite rollout_path.
  3. Restart Desktop and verify thread counts, sidebar grouping, database integrity, and reload behavior.

Possibly related: #20741 (project histories disappeared after update) and #28343 (dual state DB locations / codex_home mismatch warning).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗