[Windows][Desktop] Microsoft Store update can overwrite `local-projects` with empty state and mirror it to `.bak`

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

The second occurrence happened while the Windows package was updating from:

OpenAI.Codex 26.803.5235.0

to:

OpenAI.Codex 26.803.10989.0

The restored state has remained intact across two clean relaunches on 26.803.10989.0.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

The app is installed as the Microsoft Store/MSIX package OpenAI.Codex.

What issue are you seeing?

Codex Desktop has twice removed every registered local project from the Projects view during an in-app Microsoft Store update. The project folders and thread data were not deleted. The local-projects registry in %USERPROFILE%\.codex\.codex-global-state.json was replaced with an empty map, and the same empty state was then written to .codex-global-state.json.bak.

This is distinct from a derived thread-catalog-only failure:

• Immediately before the second update, the global state contained 12 registered local projects.
• All 12 corresponding folders still existed and remained readable.
• After the update, the Projects view showed no local projects and both the primary global-state file and its .bak contained zero local projects.
• Restoring only the project registry and its related ordering/assignment atoms from a known-good snapshot restored all 12 projects. No project source files or thread database rows needed to be recreated.
• The restored registry survived closing the app, a second launch, and a later live state save by the new version.

Correlated Windows update timeline for the second occurrence

All times below are local time on 2026-08-11:

10:43:01  Old 26.803.5235.0 desktop process launched.
10:43:45  Windows AppX deployment began removing/de-staging the old package.
10:44:12  The preferred package version changed to 26.803.10989.0.
10:44:45  .codex-global-state.json was rewritten with local project count 12 -> 0.
10:45:04  The new package completed staging/registration activity.

The Microsoft Store event source for this update included:

Update;ChatGPT-SearchForUpdatesWithPausedAddAsync
StageButDoNotInstall=1
status=BlockedOnUser

The first occurrence showed the same user-visible result during a previous AppX update: a known-good temporary global-state write was left behind while the active state subsequently contained no projects.

Backup behavior

Inspection of the installed desktop bundle's state persistence path indicates that it atomically writes the primary global-state file and then writes the same serialized in-memory state to .bak. Consequently, if the in-memory local-projects map is empty during an update/lifecycle race, both the primary file and the nominal backup are overwritten with the same empty project registry. The .bak is therefore not a previous known-good generation in this failure mode.

No raw global-state file is attached because it contains private project names, absolute paths, thread IDs, UI history, and other local metadata.

What steps can reproduce the bug?

This has occurred twice, but the update race is timing-dependent rather than deterministic.

1. Use Codex Desktop on Windows with multiple registered local projects and keep the desktop process running.
2. Confirm that %USERPROFILE%\.codex\.codex-global-state.json contains a non-empty local-projects registry.
3. Let the app's in-app Microsoft Store update flow search for and stage a newer OpenAI.Codex package while the old desktop process is still active.
4. During package removal/de-staging and new-version staging, allow the old/new lifecycle to complete normally.
5. Launch or return to the newly registered version.
6. Observe that the Projects section is empty even though every project folder still exists.
7. Inspect the primary global-state file and .bak: both contain zero local projects.

The cleanest observed reproduction updated 26.803.5235.0 to 26.803.10989.0 and produced the exact event/state timeline above.

What is the expected behavior?

• App updates must preserve registered local projects, their ordering, and thread-project assignments.
• The updater should quiesce all old-version state writers before de-staging the old package or allowing the new version to load/write shared state.
• A transition from a non-empty on-disk project registry to zero projects should not be persisted unless it is tied to an explicit user deletion transaction.
• .codex-global-state.json.bak should retain the previous known-good generation. It should not be overwritten with the same newly serialized state during the same save operation.
• If an update detects an empty/missing registry while valid prior state or valid project roots exist, the app should recover automatically or offer a supported project-index rebuild action.

Additional information

The recovery was validated as follows:

Expected registered projects: 12
Restored projects:             12
Existing project roots:        12/12
First launch after recovery:   12/12
After first clean exit:        12/12
Second launch:                 12/12
Current live app state:        12/12

This report is related to the same broad symptom described in:

• #19873 — project/sidebar list lost after update
• #34076 — local project registrations disappear while core data remains healthy
• #35088 — Projects and Recent empty after update
• #37212 — project grouping disappears after update/re-login

The additional mechanism-level evidence here is:

1. the exact AppX/MS Store update timeline;
2. a direct local-projects transition from 12 to 0 while all roots remained valid;
3. the primary file and .bak being overwritten with the same empty state; and
4. restoration succeeding by repairing the project registry without modifying project files or authoritative thread data.

I can provide sanitized Windows AppX event excerpts, state-key counts, timestamps, and hashes if a maintainer identifies the preferred secure channel. I will not post raw state, authentication files, databases, or logs publicly because they contain private local metadata.