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

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

   on May 21, 2026
2. github-actions commented on May 21, 2026

   

   github-actionsbot

   on May 21, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Undocumented active chat visibility limit in Codex app #23683
   • Codex Windows Project Chats Disappearing / Project Persistence Broken #23676
   • Codex Desktop on Windows no longer shows older chats after update #23193
   • Codex Desktop should provide safe local thread/sidebar recovery and avoid pin-state hiding active project chats #22619
   • Codex Desktop project sidebar shows empty even when threads have matching cwd #23609

   Powered by Codex Action
3. omarpinarecords commented on May 22, 2026

   

   omarpinarecords

   on May 22, 2026

   More actions

   just add the environments and select the existing folders. https://developers.openai.com/codex/app/local-environments.
4. YuchengHE-CHN commented on May 22, 2026

   

   YuchengHE-CHN

   on May 22, 2026

   More actions

   Codex Desktop: Local Threads Exist but Project Shows "No chat"

   Summary

   I ran into a case where Codex Desktop showed No chat for a project, even though the old conversations still existed locally. The issue appeared to be a Desktop UI/sidebar/search indexing problem, not data loss.

   Symptoms

   • A project in Codex Desktop showed No chat.
   • Searching for the old thread title or keywords inside Codex Desktop returned no results.
   • The thread still existed in the local SQLite database.
   • The corresponding session JSONL file also still existed under the local Codex sessions directory.

   Local Evidence

   The missing thread was present in the local threads table:

   SELECT id, title, cwd, archived, source, thread_source, updated_at, rollout_path
   FROM threads
   WHERE cwd = '/path/to/project';

   The result showed:

   • archived = 0
   • cwd matched the expected project path
   • rollout_path pointed to an existing session JSONL file
   • source was an older value, such as vscode
   • thread_source was empty for the old thread

   This confirmed that the thread data had not been deleted.

   What Did Not Work

   Simply bumping the thread's updated_at / updated_at_ms fields did not make it appear in Codex Desktop. This suggests the issue was not only caused by the thread being too old or outside the first loaded page of the sidebar.

   What Made It Reappear

   The thread appeared again after combining these steps:

   1. Resume the thread through the CLI:

   codex exec resume <thread-id> "Please reply only OK. Do not edit files or run commands." --skip-git-repo-check

   2. Ensure the thread is marked as a user-visible thread:

   UPDATE threads
   SET thread_source = 'user'
   WHERE id = '<thread-id>';

   3. Ensure the project path is present in the Desktop project order in the global state file:

   {
     "project-order": [
       "/path/to/project"
     ]
   }

   4. Fully quit and reopen Codex Desktop.

   Likely Cause

   The likely cause is an indexing or migration mismatch between older Codex/VS Code-created threads and the newer Codex Desktop project sidebar/search UI.

   In this case, the old thread was valid and unarchived in the local database, but Desktop did not include it in the visible project thread list or search results. The combination of an empty thread_source, older source metadata, missing project ordering state, and the known sidebar pagination/loading behavior made the thread effectively invisible in the Desktop UI.

   Takeaway

   This does not look like data loss. It looks like the Desktop app can fail to surface older local threads in the sidebar/search index, even when they remain recoverable through the local database and CLI.

   For anyone debugging this, check:

   • ~/.codex/state_5.sqlite
   • ~/.codex/sessions/...
   • the threads table
   • archived
   • cwd
   • thread_source
   • rollout_path
   • the Desktop global state project order

   Back up ~/.codex or the relevant SQLite/global-state files before making any manual changes.
5. TeemoDDD-Bot commented on Sep 14, 2026

   

   TeemoDDD-Bot

   on Sep 14, 2026

   More actions

   Additional reproduction on macOS with ChatGPT/Codex Desktop 26.908.40834 (build 8881). This is still happening in a substantially newer build than the one in the original report.

   Three existing ChatGPT projects currently show 0/1, 1/7, and 0/2 of their active local Codex tasks in the project sidebar. The missing tasks remain searchable and readable. For each affected task I checked, the session file exists, the core database says archived = 0, the historic project assignment is present, and the core database's project_id points to the migrated project. Restarting the desktop app did not restore the project lists.

   The desktop's local thread catalog also contains these tasks with missing_candidate = 0; they are not missing from that index. Among 90 active, top-level local tasks in the catalog, their recency ranks are:

   • Project A: 87 (sidebar shows 0/1)
   • Project B: 10, 26, 52, 71, 83, 85, 86 (sidebar shows 1/7)
   • Project C: 70, 72 (sidebar shows 0/2)

   The visible counts match the tasks in the first small recent page. Expanding the projects does not load the older members. This appears to be a project-sidebar pagination/materialization problem, not deletion or archiving. Please make project expansion load its own task history (or expose a reliable load-more/rebuild action), including tasks beyond the initial global recent page.
6. etraut-openai commented on Oct 13, 2026

   

   etraut-openai

   on Oct 13, 2026

   Contributor

   More actions

   (response from codex)

   Thanks for measuring the pagination. Closing as a duplicate of #18640, where the same first-global-page limitation hides project threads that the app-server can still return. Your 183-thread/13-root results and the missing load-on-expand behavior are useful for that investigation. The later comment about ChatGPT projects should be checked separately if it involves a different data source. Nothing here suggests the underlying listing issue is fixed.
7. etraut-openai

   closed this as a duplicateof threads / projects in sidebar missing #18640 on Oct 13, 2026