›_ Codex Issues
Codex Issues / #23825

Codex Desktop sidebar project groups only show threads from the first recent page; expanding a project does not load remaining project threads

Open 💬 3 comments Opened May 21, 2026 by laolin5564
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • Codex Desktop macOS app: 26.513.31313 (2867)
  • Bundled codex: codex-cli 0.131.0-alpha.9
  • macOS: 26.4.1
  • Arch: arm64

Problem

The local sessions were not lost, but the Codex Desktop sidebar only displayed a small subset of threads under each project. Expanding a project did not load the rest of that project's sessions.

This made it look like historical sessions had disappeared, even though they were still present locally and could be returned by the app server with pagination.

Observed behavior

  • Active session data still existed in ~/.codex/state_5.sqlite and ~/.codex/sessions.
  • Direct app-server pagination returned 183 threads across 13 workspace roots.
  • The sidebar initially appeared to show only about 5-6 threads per project.
  • Project "Show more" only expanded already-loaded thread keys; it did not request additional pages.

Expected behavior

When a project is expanded, Codex Desktop should either:

  • load all remaining threads for that project, or
  • continue paginating recent threads until the expanded project has all available sessions, or
  • clearly expose a global load-more mechanism before project-level truncation.

Evidence

  • thread/list with pagination returned pages [100, 83], total 183 unique threads.
  • Workspace counts included:
  • /Users/laolin/Desktop/linyn-kf: 41
  • /Users/laolin/Desktop/linyn-kf-qkl-refactor: 54
  • /Users/laolin/Desktop: 41
  • plus 10 other roots
  • The issue appears related to the desktop sidebar loading only the first recent conversation page, while project expand/collapse operates only on the loaded subset.

Impact

Users may believe historical Codex sessions were lost, even though the session data is still present locally.

Notes

I searched existing issues first. There are related sidebar/thread-list issues, but I did not find one specifically describing project groups being truncated because only the first recent page is loaded and project-level "Show more" does not trigger additional pagination.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23683
  • #23676
  • #23193
  • #22619
  • #23609

Powered by Codex Action

omarpinarecords · 3 months ago

just add the environments and select the existing folders. https://developers.openai.com/codex/app/local-environments.

YuchengHE-CHN · 3 months ago

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
  1. Ensure the thread is marked as a user-visible thread:
UPDATE threads
SET thread_source = 'user'
WHERE id = '<thread-id>';
  1. Ensure the project path is present in the Desktop project order in the global state file:
{
  "project-order": [
    "/path/to/project"
  ]
}
  1. 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.