Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

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

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 24, 2026
2. github-actions commented on Sep 24, 2026

   

   github-actionsbot

   on Sep 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • macOS: global-state read EPERM falls back to empty project registry while SQLite projects survive #46919
   • Windows desktop: corrupted CODEX_HOME global state resets projects/thread assignments; sessions survive but project grouping is lost #46987
   • Projects disappear after codex update #47363

   Powered by Codex Action
3. GamersaurusLex commented on Sep 26, 2026

   

   GamersaurusLex

   on Sep 26, 2026

   More actions

   The automated duplicate detector identified #47827 and #47764. These appear related, but I am leaving this report open for triage because this case reproduces on macOS, and the diagnostics differ in a potentially useful way.

   #47827 appears to be the closest match: its projects and project_roots records also remain intact after the projects disappear from the sidebar.

   In my macOS case, however, I have additionally verified that:

   • The desktop global state still contains local Codex project IDs.
   • sidebar-project-list-expanded-v1 is true.
   • The desktop application actively enumerates the missing project directories with source=sidebar_workspace_groups.
   • That scan successfully completes with worker-complete dirCount=59 ... originCount=48.
   • Despite this, no local Projects section is rendered.

   This may therefore be the same underlying cross-platform bug, but I am leaving the macOS report available so maintainers can determine whether it should be consolidated with #47827 or tracked separately.
4. emchesson commented on Sep 29, 2026

   

   emchesson

   on Sep 29, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Linux case related to this report. The public draft below is redacted; no raw logs, chat transcripts, paths, or identifiers are attached.

   [Linux Desktop 26.924] Local projects disappear from sidebar while chats remain; project membership differs across app views

   Environment

   • ChatGPT/Codex desktop app: 26.924.50649
   • OS: Ubuntu 22.04.4 LTS, x86_64
   • Bundled Codex: codex-cli 0.158.0-alpha.2.1
   • Separately installed Codex CLI: codex-cli 0.159.0
   • Date observed: 2026-09-29

   Observed behavior

   The user reports that local project folders have repeatedly disappeared from the desktop sidebar after app updates while existing Codex chats remain visible under Recents. On this occasion the sidebar showed “No projects” but still listed the chats. Quitting and restarting the app did not restore the projects. The user also reports seeing different chat/project grouping through a Connection from another device than on the host's direct desktop UI. The association with updates is user-observed; a controlled before/after update reproduction has not been captured.

   After the user created three local projects in the desktop app and pointed each at its existing folder, the projects appeared in the sidebar. One existing worktree chat was grouped automatically; many other existing chats from those folders initially remained under Recents. Whether old chats are expected to join newly created projects automatically is unclear.

   Read-only diagnostics after recreation found:

   View	Projects	Chat memberships
   Desktop local state	3 local project records	3 explicit assignments among 27 relevant existing chats
   Codex app-server database	3 project records and 3 folder roots	0 project_id values among those 27 chats
   App sidebar inventory API	3 local projects	The 3 explicit chats plus 1 worktree chat appeared grouped in the latest snapshot

   These are different state representations; the database/UI difference alone is not proof of corruption. The user-visible problem is that projects and chat grouping can disappear or differ between direct and Connected views, with no apparent recovery or reconciliation path. The underlying chat records and folder roots remained present in this investigation.

   Expected behavior

   Existing local projects should remain visible across app updates and restarts. Direct and Connected views should identify the same host projects and chat memberships, or clearly explain when a project/chat exists only in one view. If migration or synchronization is incomplete, the app should recover or offer a supported reconciliation action without creating duplicate projects.

   Reproduction and diagnostics requested

   1. Save local projects and chats on a host, including chats in a project worktree.
   2. Update/restart the desktop app and compare the direct host sidebar with a Connection from another device.
   3. Compare the app's local project registry, app-server project/list, and sidebar project/chat inventory.
   4. Check whether existing chat memberships are preserved and whether the UI can rebuild its project registry from intact backend project records.

   This case occurred on Linux. Related open reports cover disappearing projects on Windows and project metadata drift between Remote and Desktop: #47764, #48501, and #42321.

   Redacted diagnostics and a screenshot can be provided privately. No raw transcripts or databases should be posted publicly.