Codex Desktop project sidebar does not hydrate older project threads, even though thread/list with cwd can return them

Open 💬 1 comment Opened Jun 10, 2026 by Alex-ghost599

Codex App version

26.608.12217

Subscription

Redacted. I can provide this privately if needed.

Platform

macOS, arm64

What issue are you seeing?

Codex Desktop still hides older local project threads from the project sidebar, even though the local data is present and the app-server can return the missing threads when queried by project cwd.

This does not look like data loss. The affected threads are still in local storage, are not archived, and can be read by direct thread id. The failure appears to be in the Desktop sidebar hydration path: project grouping only receives a recent global candidate set, then groups those already-loaded thread keys. It does not appear to fetch missing threads for a project when that project is expanded.

I know there are related reports, including #23825, #27159, #20833, and #18640. I am opening this as a focused data point because thread/list with a cwd filter can return the missing project thread, while the Desktop project sidebar still shows no chats for that project.

What steps can reproduce the bug?

I am using redacted paths and ids below.

  1. Have a local Codex profile with many active local threads across multiple project roots.
  2. Keep an older, unarchived project thread whose cwd exactly matches a saved project root.
  3. Restart Codex Desktop.
  4. Open the project in the Desktop sidebar.
  5. The project may show No chats, or may omit older chats, even though the thread still exists locally.

Local checks:

SELECT id, title, cwd, archived, updated_at, rollout_path
FROM threads
WHERE cwd = '/path/to/project'
ORDER BY updated_at DESC;

The affected thread is present, with:

archived = 0
cwd = /path/to/project
rollout_path = existing rollout JSONL file

Direct app-server checks:

thread/list limit=50  -> 50 rows, nextCursor present
thread/list limit=100 -> 100 rows, nextCursor present
thread/list limit=150 -> 100 rows, nextCursor present
thread/list limit=500 -> 100 rows, nextCursor present

So the runtime page size appears capped at 100.

With normal global pagination, the affected project thread was outside the first recent page. However, querying by exact cwd returned it immediately:

{
  "method": "thread/list",
  "params": {
    "limit": 50,
    "cursor": null,
    "sortKey": "updated_at",
    "archived": false,
    "cwd": "/path/to/project"
  }
}

That returned the missing thread with the expected cwd and existing rollout path.

I also checked the Desktop renderer bundle. The project grouping path appears to consume already-loaded threadKeys; project expand/show-more expands the already-loaded subset and does not trigger a cwd-specific thread/list query. That matches the observed behavior.

What is the expected behavior?

If a saved local project has active, unarchived local threads whose cwd matches the project root, the project sidebar should show them.

Expanding a project should either:

  • call thread/list with a cwd filter for that project,
  • keep paginating recent threads until all threads for the expanded project are loaded,
  • or provide a clear all-local-threads view/search that is not limited to the current recent candidate set.

Sidebar search should also be able to find persisted local threads, not only hydrated recent threads.

Additional information

Things I tried that did not solve the issue:

  • rebuilding thread-workspace-root-hints
  • rebuilding sidebar-project-thread-orders
  • rebuilding thread-project-assignments
  • unpinning/pinning checks
  • restoring the original timestamps after temporarily lifting the thread into the recent window

Temporarily lifting the affected thread timestamp made it appear again. Restoring the original timestamp made it disappear again. That strongly suggests the project sidebar depends on a freshness-limited candidate set.

The useful API already seems to exist: thread/list with cwd can return the missing project threads. The Desktop sidebar just does not seem to use it for project hydration.

A supported rebuild/reindex command, or project-level cwd hydration in the sidebar, would prevent valid local history from looking deleted.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗