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

Activity

1. badarshahzad

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 18, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Aug 18, 2026
3. github-actions commented on Aug 18, 2026

   

   github-actionsBot

   on Aug 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows] NUL-corrupted state wipes projects and backup #38757
   • Project related conversations disappears from projects #38956

   Powered by Codex Action
4. ArcGG33 commented on Aug 19, 2026

   

   ArcGG33

   on Aug 19, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. ArcGG33 commented on Aug 19, 2026

   

   ArcGG33

   on Aug 19, 2026 – with ChatGPT Codex Connector

   More actions

   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.
6. Shedletsky commented on Aug 20, 2026

   

   Shedletsky

   on Aug 20, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. suqinghechina-debug commented on Aug 26, 2026

   

   suqinghechina-debug

   on Aug 26, 2026

   More actions

   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.
8. miruronpa commented on Aug 26, 2026

   

   miruronpa

   on Aug 26, 2026 – with ChatGPT Codex Connector

   More actions

   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.
9. roysht commented on Aug 27, 2026

   

   roysht

   on Aug 27, 2026 – with ChatGPT Codex Connector

   More actions

   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.
10. Zef76 commented on Aug 27, 2026

    

    Zef76

    on Aug 27, 2026 – with ChatGPT Codex Connector

    More actions

    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.
11. naipi11 commented on Aug 27, 2026

    

    naipi11

    on Aug 27, 2026 – with ChatGPT Codex Connector

    More actions

    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.
12. roysht commented on Aug 28, 2026

    

    roysht

    on Aug 28, 2026 – with ChatGPT Codex Connector

    More actions

    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.
13. Ludosofo commented on Sep 1, 2026

    

    Ludosofo

    on Sep 1, 2026 – with ChatGPT Codex Connector

    More actions

    Additional report from another Windows Desktop/Codex user seeing the same broad class of failure.

    Observed pattern:

    • After ChatGPT Desktop / Codex updates, Codex loses the local folder/project references it had been working with.
    • Existing work is not perceived as continuing from the expected local project folder.
    • New/current sessions can start in a generated Codex directory rather than the user's intended persistent project folder.
    • The issue has occurred multiple times, temporally correlated with ChatGPT/Codex updates.
    • The practical impact is loss of continuity and a risk that Codex may read, search, or edit from the wrong working directory unless the user manually checks the folder again.

    Current affected environment, sanitized:

    • Platform: Windows Desktop / ChatGPT Codex
    • Date observed: 2026-09-01
    • Expected behavior: local projects should retain attached folders, primary folder, and task/project association across app updates.
    • Actual behavior: Codex appears to lose the project/folder association and falls back to a generated workspace-like directory for the session.
    • Example current working directory shape after the issue, redacted: %USERPROFILE%\Documents\Codex\YYYY-MM-DD\<generated-task-folder>

    This matches the user-visible symptoms in this issue: historical/local project associations not surviving updates, even when the user's underlying project folders still exist. I do not have a sanitized global-state snapshot or exact app version from the About dialog yet, but wanted to add another occurrence so maintainers can see this is recurring across Windows Desktop users.

    No raw paths, account data, state files, logs, or task databases are being posted publicly because they may contain private local metadata.
14. tsammalvuo commented on Sep 4, 2026

    

    tsammalvuo

    on Sep 4, 2026 – with ChatGPT Codex Connector

    More actions

    Additional independently observed Windows occurrence — 2026-09-04

    I am seeing the same structural failure in ChatGPT Desktop / Codex on Windows: historical local projects are missing while their task records and transcripts remain available.

    Sanitized read-only diagnostics

    • The live project-list API returned exactly 1 local Codex project (a current/newer project).
    • The sidebar Projects section likewise contained exactly one codex:project:* entry; unrelated ChatGPT cloud projects were still present.
    • list_threads(limit=50) exposed 22 recent historical Codex tasks across 9 distinct historical working-directory paths. Every affected task had projectId: null and status: "notLoaded".
    • The archived-task listing contained 9 additional historical tasks across 2 canonical project roots, also with projectId: null.
    • The surviving tasks can still be discovered and opened, and their original working-directory metadata remains present.
    • unavailableHosts and unavailableSources were both empty, so this is not explained by an unavailable registered host/source.
    • A new/current task started in a generated directory shaped like %USERPROFILE%\Documents\Codex\YYYY-MM-DD\<generated-task-folder> rather than under one of the missing historical projects.

    This evidence is consistent with loss or failed hydration/migration of the local-project catalog and thread-to-project assignments, not deletion of the historical task records. It does not establish the trigger or root cause.

    Diagnostic limitation

    A direct on-disk existence check could not be completed because local command execution and browser automation in the diagnostic task both failed before process launch with:

    windows sandbox failed: helper_unknown_error: apply deny-read ACLs

    That sandbox failure may be unrelated; no causal link is claimed. No configuration, registry, database, session, or project files were modified.

    Expected behavior

    Historical local-project registrations and thread associations should survive updates/restarts, or the app should provide a supported backup-first Repair/Rebuild Projects operation.

    Privacy: project names, raw filesystem paths, task/session identifiers, account data, and conversation contents are intentionally omitted from this public report.
15. Meaty031 commented on Sep 6, 2026

    

    Meaty031

    on Sep 6, 2026

    More actions

    I can reproduce this regression on Windows with Codex Desktop 26.901.20858 (bundled Codex 0.153.0-alpha.5).

    The problem appeared immediately after an app update and persisted after updating again. At the same time, ChatGPT projects—which had never previously appeared in my Codex sidebar—were added to the unified Projects section, while all historical local Codex projects and their task associations disappeared.

    Sanitised read-only audit

    This is not task deletion and is not caused by unavailable project folders:

    • Eight historical local projects are missing from the desktop Projects sidebar.
    • All eight saved project-root folders still exist and remain accessible on disk.
    • %USERPROFILE%\.codex\state_5.sqlite still contains the eight historical project registrations.
    • The corresponding project_roots entries retain their original absolute paths.
    • The database contains 1,292 task records whose working directories match those project roots.
    • All 1,292 affected task records now have project_id set to null.
    • The underlying sessions remain present and readable.
    • Only local projects registered after the update are returned by the desktop app.
    • Updating and restarting again does not rebuild the associations.

    The affected roots use structures such as:

    C:\[personal-work-root]\[projects-folder]\[project-folder]

    Some projects have multiple saved roots, including a parent workspace and a specific project root:

    C:\[workspace-root]

    C:\[workspace-root]\[project-folder]

    All of these folders still exist. The projects are therefore not being hidden because their paths are missing or inaccessible.

    Task working directories match those roots but are stored in the extended Windows form, for example:

    \\?\C:\[personal-work-root]\[projects-folder]\[project-folder]

    The project-root table stores conventional paths without the extended-length prefix. After normalising that prefix, the task paths match the saved roots. This difference may be relevant to migration or matching logic.

    For one project whose folder was later registered at another location, historical tasks still reference the original path while the new project uses the new path. However, folder relocation is not the primary cause: seven other historical projects also disappeared even though their registered roots have not moved and still exist.

    The database records a successful projects recency schema migration on 2026-09-05. The symptoms appeared following the associated update. This suggests the update/sidebar migration failed to rehydrate historical local projects and left their task mappings orphaned.

    Affected tasks can still be opened directly and placed into custom sidebar sections. That restores visibility but not their actual project relationships. Re-registering a folder creates a new visible project instead of reconnecting the historical project and tasks.

    Expected behaviour

    • Existing local projects and task-to-project relationships should survive updates.
    • Introducing ChatGPT cloud projects should not replace or hide local projects.
    • Conventional and extended-length Windows paths should be normalised during matching.
    • The app should offer a supported project-index rebuild and task reassociation workflow.
    • Users should be able to map an old project root to a newly registered root.
    • ChatGPT cloud projects and local Codex projects should be clearly distinguished.

    I have not attached raw databases or logs because they contain private task titles, prompts, project names, folder names, and account information. Sanitised rows or selected excerpts can be provided through an appropriate secure channel.

    👍React with 👍1Reacted by roseyrose
16. shawnholt commented on Sep 15, 2026

    

    shawnholt

    on Sep 15, 2026

    More actions

    please consider adding a doctor command to restore this mess.
17. fsrm00 commented on Oct 3, 2026

    

    fsrm00

    on Oct 3, 2026

    More actions

    Additional Windows recovery experience (2026-10-03, installed package version 26.930.3748.0): my local project folders and old chats survived, but project entries disappeared and many unarchived chats remained outside the recreated projects.

    After recreating the project entries with the correct local folders, a single-chat test and then a reviewed batch succeeded by fully exiting Codex, backing up .codex-global-state.json, and removing only the selected chat IDs from projectless-thread-ids. After reopening, I confirmed that project grouping had recovered. The batch removed 82 selected IDs out of 90 explicitly projectless, unarchived chats; 8 deliberately independent or ambiguous chats were preserved. File verification confirmed those counts, but it does not prove that every one of the 82 chats was assigned to the correct project.

    A useful comparison: two unarchived chats had the same working directory. The one already grouped under the recreated project was absent from projectless-thread-ids; the one remaining outside the project was present. Removing that marker while the app was closed restored grouping in the single-chat test. This suggests that an explicit projectless marker can prevent directory-based matching in this version; it is an inference, not a verified source-code mechanism or proof of the original update failure.

    Earlier attempts to write a project ID into SQLite, or to supplement associations while the client was running, did not restore the UI reliably. The successful batch only filtered the JSON array above; it did not change chat contents, project files, or archive status. A helper launched from inside the active Codex session also stopped before performing the write; launching it separately from File Explorer and then fully quitting Codex worked.

    Please distinguish restoring project membership from archiving chats. Also, do not clear the entire projectless list or assign every chat by directory alone: shared folders, nested roots, and conflicting historical membership can produce incorrect associations. I used historical mappings first, then directory and title evidence, excluded conflicts, made backups, and verified a single chat before batching.

    This is an independent, version-specific recovery experience, not an official or universal fix. No raw state, database, authentication files, private paths, or real chat IDs are included. An official backup-first Repair/Rebuild Projects and reviewed chat reassociation workflow would avoid this manual recovery.