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

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

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 ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33016
  • #33771

Powered by Codex Action

PrinnyQ · 1 month ago

Sanitized recovery result after reproducing this on the same installation:

  • Took timestamped backups of the global state, SQLite DB, and affected rollout.
  • Remapped all 35 legacy path-based thread assignments to the corresponding new local-... IDs.
  • Repaired project ordering and restored one legacy project record: project count 6 -> 7.
  • Post-repair stale assignment count: 0.
  • State DB still has 261 threads and PRAGMA quick_check is ok.
  • Copied the affected 32.4 MB rollout to WSL-local storage, verified the original/backup/WSL SHA-256 hashes are identical, updated rollout_path, and moved the Windows original into the timestamped recovery directory.
  • After restarting Desktop, the missing project histories returned and the user confirmed that opening the affected thread no longer freezes the UI.

Important: this is a performance workaround, not a fix for the reload loop. Post-restart logs still show 66 recorder messages (about 33 full thread/turns/list reloads) for the same 14,081-record rollout over 62 seconds. They now read from the WSL-local path and complete quickly enough that the UI remains responsive. The app also emitted 157 additional state db codex_home mismatch warnings after restart because other rollouts remain under the Windows-side Codex home.

This confirms two independent upstream problems:

  1. project-ID migration leaves thread assignments in the legacy namespace; and
  2. large-thread thread/turns/list requests enter a repeated full-rollout read loop.

Moving a large rollout to WSL-local storage masks the second problem by reducing I/O latency, but the repeated requests remain observable in logs.

JRJC2121 · 1 month ago

Reproduced on Codex App version 26.715.10079.0 (Windows 11, Microsoft Windows NT 10.0.26200.0 x64), triggered by the same auto-update pattern described here — Store package OpenAI.Codex updated on 2026-07-22.

Additional diagnostic detail that might help narrow down the mapping bug: in ~/.codex/.codex-global-state.json:

  • sidebar-project-thread-orders (which appears to drive the per-project sidebar list) contained only 1 project entry (3 threads) out of 6 known local projects — the rest were empty/missing.
  • pinned-thread-ids and thread-project-assignments (14 entries) were still populated and correctly resolved — this is why pinned threads kept working while regular ones disappeared, matching the "legacy project ID" theory here.
  • Underlying data confirmed fully intact: 154 rollout-*.jsonl session transcripts under ~/.codex/sessions/ and ~/.codex/archived_sessions/, dated 2026-06-11 through 2026-07-21.
  • A full quit + relaunch of the app did NOT repopulate sidebar-project-thread-orders, nor touch the legacy session_index.jsonl / codex-history-snapshots-dev.db files (timestamps unchanged before/after restart) — no automatic reindex/migration runs on startup, consistent with the "failed to remap thread-to-project assignments during migration" root cause described here.

Happy to share the full (PII-redacted) state file structure if useful.