[Windows][Desktop 26.810.7004.0] Historical local projects disappear after update while tasks remain intact and newer projects work

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

• #38757
• #38956

Powered by Codex Action

I am experiencing a closely related Windows regression after the current Codex Desktop → ChatGPT Desktop transition, but with an even more severe failure mode.

Environment / observed behavior:

• Windows desktop app updated and required re-authentication.
• I signed back in with the same ChatGPT account; normal ChatGPT history loads correctly.
• Codex shows 0 projects and only newly created post-update items.
• Before the update, the Codex Desktop app contained active local projects and ongoing work history that I relied on for production work.
• After the update, those projects and prior Codex history are no longer accessible from the UI.

Local forensic checks already performed:

• %USERPROFILE%\.codex exists, but the current sessions tree contains only a newly created session from Aug 19, 2026.
• session_index.jsonl, state_5.sqlite, and .codex-global-state.json are present but appear to belong to the newly initialized post-update state.
• A recursive search under the Windows user profile did not find older rollout-*.jsonl files.
• The older Windows MSIX package path (OpenAI.Codex_2p2nqsd0c76g0) still exists, but its LocalState/RoamingState/LocalCache do not contain the missing conversation history.
• Re-authenticating with the same account does not restore anything.
• The current .codex directory has been backed up before any further repair attempts.

This is materially different from a cosmetic sidebar bug when the user can no longer access the historical sessions needed to continue ongoing work. From the user’s perspective, inaccessible project history is functionally equivalent to lost project history until a supported recovery path exists.

OpenAI’s migration guidance states that existing Codex chats/projects should remain after the transition. In this case they did not.

Please treat this as a data-continuity / migration incident, not merely a UI issue, and provide:

1. An official supported recovery procedure for pre-update Codex Desktop projects and chats.
2. The authoritative pre/post-migration storage locations on Windows.
3. A supported re-index / backfill / import command or UI action.
4. Guidance on whether reinstalling is safe or risks overwriting further recoverable state.
5. Confirmation whether OpenAI retains any server-side metadata or recoverable mapping for local Codex projects that disappeared during this migration.

Please do not require users to publicly upload full .codex databases or transcripts as a first step: these files may contain private conversation content, local filesystem paths, repository names, and account-related metadata. If diagnostic artifacts are required, please provide a redaction-safe procedure or private upload channel.

Severity: blocking. This regression has interrupted active paid production work and removed access to project context immediately after an app update/re-authentication flow.

I want to add a legal/consumer-protection dimension because this failure mode should not be characterized merely as a cosmetic sidebar regression.

I am not alleging intentional deletion. I am asking OpenAI to address the legal and contractual consequences of making paid users’ existing digital work product and project history inaccessible immediately after a vendor-controlled update and re-authentication flow.

Functional effect

From the user’s perspective, there is no meaningful operational distinction between:

• deleting a project history,
• corrupting the index required to retrieve it,
• migrating it into an unreachable state,
• or rendering it inaccessible with no supported recovery mechanism.

In each case the user loses the ability to possess, use, inspect, continue, export, or recover the digital work product on which ongoing work depends. If the service itself performed the update that caused that state, the resulting loss of access should be treated as a data-continuity and service-performance incident, not dismissed as a UI inconvenience.

Paid digital service / allocation of risk

OpenAI’s own Terms of Use acknowledge the possibility of loss of data and expressly state that liability limitations apply only to the maximum extent permitted by applicable law. That qualification matters. A standard-form disclaimer does not automatically answer whether a vendor may shift to a paying user the entire risk of a vendor-controlled migration failure that makes accumulated work product inaccessible.

For users in Taiwan, this raises at minimum questions under the Consumer Protection Act’s principles governing standard-form contracts. The Executive Yuan Consumer Protection Committee explains that:

• Article 11 requires standard-form terms to follow the principle of equality and reciprocity;
• Article 12 provides that terms contrary to good faith and manifestly unfair to consumers are invalid;
• a term may be considered inconsistent with equality and reciprocity where the consumer is made to bear risks that are not within the consumer’s control.

A forced or vendor-controlled update is, by definition, not a risk the end user controls. If the result is loss of access to accumulated paid-service work history, OpenAI should explain what safeguards, rollback, recovery, and preservation mechanisms existed and why the user should bear the consequences of their failure.

Preservation / spoliation concern

Now that this class of failure has been repeatedly reported, OpenAI should preserve relevant migration, authentication, synchronization, project-registry, and account-mapping logs associated with affected users. Users should not be instructed to reinstall, reset, clear local state, or overwrite databases before OpenAI states clearly whether those actions could destroy evidence or recoverable state.

This is especially important where support or engineering may later need to determine whether the missing material still exists in remote metadata, an account-level project registry, migration caches, or server-side mappings.

Requested response

Please provide a concrete answer to the following:

1. Does OpenAI classify inaccessible pre-update Codex project history as a data-loss/data-continuity incident when no supported recovery path is available?
2. What is the authoritative source of truth for pre-update Windows Codex projects and chats?
3. What preservation steps should affected users take before reinstalling or resetting the app?
4. Does OpenAI retain server-side project/thread metadata that can be used to restore local project associations?
5. Is there an internal recovery or reindex tool that Support can run for affected accounts?
6. If recovery is impossible, what remedy is OpenAI offering paying users whose accumulated work context became inaccessible as a direct consequence of the update?
7. What safeguards will be added so future migrations are transactional, reversible, and do not commit until preservation/backfill succeeds?

Again, I am deliberately avoiding claims of intentional destruction. The issue is simpler and more serious: a paid software provider shipped an update after which accumulated user work became inaccessible, and the user currently has no supported means to recover it. OpenAI should address that as an incident involving continuity of digital assets, contractual performance, preservation, and consumer protection—not merely UI state.

Additional confirmed occurrence on Windows with Codex Desktop 26.814.5517.0.

This instance had the same core failure, with more detailed local-state evidence:

• The primary state_5.sqlite passed integrity checks and still contained 4,522 thread rows (4,197 active).
• The desktop local_thread_catalog still contained 1,036 tasks across 73 distinct working directories. Historical tasks retained correct CWD values.
• Despite that intact data, every historical task was exposed with projectId: null, and the live project API returned zero local projects.
• %USERPROFILE%\.codex\.codex-global-state.json contained an empty "local-projects": {} registry and no effective thread-to-project assignments.
• The migration markers already included 2026-07-13-local-projects and 2026-07-14-repair-metadata-local-projects, so the app considered the relevant migration/repair complete even though the registry was empty.
• This incident also had a malformed logs_2.sqlite. Quarantining it allowed Codex to create a healthy replacement, but did not regenerate local projects, so I cannot establish causality between the log DB corruption and the project-registry loss.

A backup-first reconstruction from the catalog CWDs restored 17 local projects and 1,024 task-to-project assignments. After restart, the live Codex project API reports all 17 local projects again. No task contents or source files were modified.

This points to an inconsistent split-brain state: task/CWD history remains in SQLite, while the separately stored JSON project registry and membership can be empty even though the migration markers say repair already ran.

Suggested recovery behavior:

1. Make the project migration/repair idempotent.
2. On startup, if local-projects is empty (or assignments are missing) while the catalog contains historical CWDs, automatically reconstruct project candidates/assignments or offer a one-click repair.
3. Consider storing project registry/membership transactionally with the catalog, or at least validate the JSON state before marking the migration complete.

I have intentionally omitted local paths, project names, chat contents, and raw database files. Sanitized diagnostics can be provided privately if needed.

Confirmed on Windows after the latest Codex Desktop update.

Observed behavior:

• Existing local repository files and task history are still present and accessible by absolute path.
• The app project listing returns only ChatGPT/cloud projects; the current local Git repository is absent.
• As a result, creating a new Codex task targeted at the saved local project (including automatic worktree creation) is unavailable.
• A projectless task still works when given an explicit local repository path, and a manually created Git worktree also works as a temporary workaround.

Expected behavior:

• Previously saved local projects should remain listed after update and should be selectable as targets for new local/worktree tasks.

Environment:

• Windows x64, OS build 26200
• Codex Desktop executable install directory build identifier: d0097be4feba73d0

No repository contents or credentials are included in this report.

I’m seeing essentially the same failure on Windows Codex Desktop, and it has now happened to me three times.

Typical sequence:

1. I leave the PC in sleep mode overnight.
2. By the time I return, Windows has been forcibly restarted (I cannot yet confirm whether a Codex/Microsoft Store update occurred during that restart).
3. After launching Codex Desktop, all of my local projects have disappeared from the Projects list.
4. The underlying conversations are not deleted — they are still visible under Recent.
5. The local project folders are also still present on disk.

So this looks like the same project-registry / thread-to-project-assignment loss described here, rather than actual conversation deletion.

This is extremely disruptive. Projects are the primary organizational structure for ongoing local work; silently dropping every project association after a restart makes the application look as if major work has been lost and forces manual recovery/reconstruction.

Please prioritize this. At minimum, Codex Desktop should:

• persist project mappings atomically so a crash/reboot/update cannot replace them with an empty registry;
• automatically rebuild project associations from durable thread metadata / cwd when the registry is missing or inconsistent;
• provide an official Repair/Rebuild Projects command instead of requiring users to edit internal JSON/SQLite state;
• keep recoverable backups that are not overwritten by the same bad state.

The fact that the conversations survive in Recent strongly suggests the durable information needed for recovery still exists. Losing the UI/project index should be treated as a rebuildable cache failure, not as permanent project-state loss.

I am experiencing the same project-registry/sidebar failure on Windows, and the problem still persists on a newer desktop build.

Environment

• Application: ChatGPT powered by Codex & OWL
• Current version: 26.820.71523
• Platform: Windows x64
• Subscription: ChatGPT Pro
• Observed: August 2026

What is happening

After a ChatGPT/Codex desktop update, all of my existing Codex projects disappeared from the Projects list in the Windows desktop application.

The underlying projects, chats, and synchronization do not appear to have been deleted:

• All affected chats remain accessible through Search/Recents and open normally.
• Hovering over an affected chat on Windows still shows its original project association.
• The complete original project list remains visible in Codex Remote in the ChatGPT iOS application.
• Existing affected chats can still be continued normally.
• New chats created on the Windows desktop synchronize successfully and can be found on iOS.
• The issue remains after updating the Windows desktop application again to version 26.820.71523.

Cross-device synchronization test

I performed the following test:

1. Created a new test project in Codex on the Windows desktop.
2. Started a new chat inside that project.
3. Confirmed that the new chat synchronized successfully and could be found in the iOS application.
4. Confirmed that the normal Windows desktop project list still did not repopulate.

This indicates that account/chat synchronization is working, while the Windows desktop project registry, sidebar index, or project-list hydration is failing.

Troubleshooting already attempted

• Fully quit and reopened ChatGPT/Codex.
• Restarted Windows.
• Signed out and signed back into the same ChatGPT account.
• Confirmed that the same account and workspace are selected.
• Confirmed that the projects remain visible on iOS.
• Confirmed that the affected chats remain searchable, accessible, and functional.
• Installed the newest desktop update offered to me and tested again on version 26.820.71523.

None of these steps restored the Windows desktop project list.

Expected behavior

All existing projects and their chat groupings should remain visible after a desktop application update. The Windows desktop app should rebuild or reconcile the Projects list from the valid project and thread metadata that clearly still exists.

Actual behavior

Chats and project associations remain intact and synchronize across devices, but the Windows desktop Projects list no longer displays the projects.

Data-safety concern

I have intentionally not reset the application, cleared application data, manually edited the local Codex database/global-state files, recreated all of the missing projects, or applied unofficial recovery scripts. Because the chats and project associations are still present, those actions could overwrite valid metadata or make recovery harder.

Please investigate the Windows desktop project-registry/sidebar synchronization and provide a supported way to rebuild the Projects list without deleting or recreating the existing projects. I can provide sanitized diagnostics or a feedback/session ID privately if requested.

Additional Windows observation — 2026-08-27

I am seeing the same missing local-project registration symptom, with the entire local Projects list now empty.

Environment

• Installed Windows package: OpenAI.Codex 26.820.10647.0, obtained with Get-AppxPackage (package version, not a version copied from the About dialog).
• OS: Microsoft Windows NT 10.0.26200.0, x64.
• Desktop UI language: German.

Observed behavior and verified diagnostics

• The Projects section shows “Projekte: keine” (Projects: none); a previously listed local project is missing.
• The app's project-list tool returns no saved local projects.
• Read-only inspection of %USERPROFILE%\.codex\.codex-global-state.json found:

{
  "local-projects": {},
  "selected-project": null
}

• The affected project directory still exists. Git can read its current branch and latest commit.
• Existing related tasks are still discoverable through the app's task-list tool, with projectId: null.
• The recent turns of an existing related task remain readable through the app's task-read tool.

This distinguishes the observed symptom from deletion of the project directory or loss of access to all task history. The immediate observable state is an empty local-project registry.

Limits of the observation

The exact transition that cleared the registry has not been captured. I cannot confirm an update, migration, synchronization operation, or user action as the trigger. There is no reliable reproduction sequence yet, and this comment does not claim to establish the root cause.

The investigation did not modify the app configuration or registry. Re-adding the existing folder was suggested from the official troubleshooting documentation, but recovery and restoration of historical task associations have not been tested.

Expected: saved local projects and their task associations remain available, or the app provides a supported recovery path when those registrations are missing.

Privacy: personal filesystem paths, project names, project contents, task/session identifiers, account details, and full configuration/log files are deliberately omitted.

If local projects disappear from the Projects list after an update or restart, the underlying chats and files are usually still on disk. This is a recovery method for restoring access to the affected tasks, not a fix for the project registry itself:

1. Pin any affected task that is still visible in Recent or Search so it stays on screen.
2. From a terminal run codex resume --all and open the missing task by its id or name. In Desktop, opening the opaque thread id directly also works (the task may show as notLoaded first, then loads).
3. After it opens, pin it or send a new message so it stays inside the loaded window.
4. Before assuming data loss, confirm the local store is healthy: the thread still exists in state_5.sqlite and PRAGMA quick_check returns ok.

Limitations: this restores visibility and continued access to existing tasks, but it does not rebuild the empty local-projects registry, so the project may still not reappear under Projects until a later update rebuilds the assignments.

Independent community workaround; not an official OpenAI fix.

Update: recovery succeeded on Windows desktop 26.820.71523

I successfully restored the missing Projects list. The underlying chats had not been deleted; the failure was in the local project catalog and its thread-to-project associations.

Verified diagnostics

• SQLite still contained 639 thread records with working-directory metadata.
• The SQLite projects, project_roots, and project_idempotency_keys tables contained no project records.
• Every threads.project_id value was null.
• The primary and shadow global-state JSON files contained only one incomplete/current local-project record and one assignment.

The available evidence confirms a catalog/association-state failure. It does not establish whether the trigger was the desktop update, migration, an unclean shutdown, or a synchronization/hydration defect.

Repair performed

A backup-first community repair reconstructed the project catalog using nine explicitly reviewed project roots and surviving local thread metadata. The successful plan modified only these JSON keys:

• local-projects
• project-order
• thread-project-assignments
• thread-workspace-root-hints

The primary and shadow global-state JSON files were replaced atomically after validation. SQLite was opened read-only and was not modified. No chats, prompts, transcripts, session files, source files, authentication data, or cloud/account state were changed.

After restarting the desktop application:

• The project registry contained nine total projects.
• The reconstructed mapping contained 74 user-facing task associations.
• Existing chats remained intact and accessible.
• Tasks appeared grouped under the restored Projects list.
• SQLite remained unchanged.

Internal agent records were excluded, explicitly projectless records were preserved, and 502 internal records were not assigned.

Before writing, the repair required a fully closed application, stable file fingerprints, a successful SQLite integrity check, hash-bound planning, checksum-validated byte-for-byte backups, atomic writes, and rollback metadata.

Important warning

This was an independent community workaround, not an official OpenAI fix. The exact modernization that produced this recovery is currently local and unpublished. The older public repair repository was only the starting point and should not be presented as containing this version-specific fix.

Do not reconstruct projects blindly from every recorded working directory. Nested repositories, worktrees, temporary folders, and internal agent directories can produce incorrect projects or associations. Complete backups and a privacy-redacted, read-only dry run are essential.

OpenAI should add an official Repair/Rebuild Projects function that can detect and safely recover an empty or inconsistent local project registry.