›_ Codex Issues
Codex Issues / #35090

Codex Desktop: active thread appears at bottom despite newest recency after pin/unpin

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

Summary

Codex Desktop can render an active, recently updated project thread at the bottom of the sidebar even though local/backend ordering sources place it near the top.

This appears to be a Desktop sidebar ordering/cache bug observed after opening several older threads and pinning/unpinning them. The underlying conversation remains intact and active.

Environment

  • Codex Desktop: 26.721.30844 (build 5813)
  • Embedded Codex Framework: 150.0.7871.128
  • macOS: 26.5.2 (25F84)
  • Architecture: arm64

Steps to reproduce

  1. Have an existing project thread with recent or in-progress conversation activity.
  2. Open several older project threads sequentially.
  3. Pin those threads, then unpin them so they should return to normal recency sorting.
  4. Continue the newest thread and confirm that its latest turn is in progress.
  5. Inspect the Desktop sidebar.

Expected behavior

The active thread should appear near the top according to its latest conversation/recency timestamp. Unpinning should return a thread to normal recency ordering.

Actual behavior

The active thread is displayed at the bottom of the Desktop sidebar. Re-navigating to the thread does not refresh the visible order.

Anonymous local evidence

  • archived = 0
  • pinned thread count = 0
  • thread status: active
  • newest turn status: inProgress
  • SQLite recency_at: current time, rank 3 among visible active threads
  • SQLite updated_at: current time
  • list_threads API position: 4
  • Desktop sidebar position: bottom
  • The rollout JSONL exists and is readable

The canonical session, SQLite state, and thread-list API agree that the thread is recent and active; only the visible Desktop sidebar order disagrees.

Additional observations

  • The issue initially looked like recent conversations had disappeared, but direct thread reads confirmed no data loss.
  • Pinning/unpinning was attempted as a visibility workaround. After unpinning, the Desktop view remained stale even though backend pinned state and recency order were correct.
  • Restarting was intentionally not tested while the affected thread was actively running.

Suggested fix direction

  • Recompute the unpinned sidebar list from canonical recency state after pin/unpin mutations.
  • Invalidate renderer/sidebar caches when pinned state or recency_at changes.
  • Add a consistency check when visible sidebar order disagrees with list_threads ordering.
  • Provide a safe user-facing Reload/Reindex conversations action that does not require restarting active work.

Related but not exact duplicates:

  • #31836 — project-level Sort by Last updated does not reorder projects
  • #25463 — local conversations remain readable but Desktop project views/search become stale

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34139

Powered by Codex Action

AdrianNO1 · 22 days ago

I have a similar problem. Chats are unordered, and new chats seemingly appear in a random position around the top of my chat list under a project. It also incorrectly marks old chats as unread when i restart or update the app.

Massive-Bro · 20 days ago

Additional Windows Desktop reproduction — importantly, this does not require a pin/unpin action.

Reproduction

  1. Open a local project in the Desktop app using the By project sidebar view.
  2. Start a normal new chat from inside that project.
  3. The new chat initially appears at position 1 in the project's chat list.
  4. Shortly afterward, while it is still working—or sometimes after it completes—the chat jumps down the project list.
  5. In a project with enough chats, it can move below the collapsed Show more cutoff and become difficult to find.

Expected

A newly created or actively updated unpinned chat should remain first (or near the top according to canonical recency) within its project.

Actual

The visible project list moves the new/active chat below older chats, sometimes behind Show more. This is separate from the pinned area: pinned chats are displayed elsewhere, and the affected project-list ordering is the problem.

Read-only local evidence

  • The affected chats were not archived.
  • Their recorded working directory matched the saved local project.
  • SQLite creation, update, and recency fields were current.
  • A fresh canonical thread-list read placed the newest unpinned chat correctly near the top.
  • Earlier list snapshots temporarily returned a missing/null project association for the same newly created chats, then later resolved the correct project ID.

That last transition suggests an optimistic-creation / metadata-reconciliation race: the renderer initially inserts the chat correctly, then re-sorts against an incomplete thread record and fails to repair the visible project list after full project/recency metadata arrives.

No session transcripts, private paths, or authentication data are included here.

Suggested regression coverage: create a normal unpinned chat in a project whose visible list is long enough to show Show more, reconcile its title/status/project association asynchronously, and assert that it remains first according to canonical recency without requiring a project switch or app restart.

vtsixthai · 19 days ago

I am seeing a similar sidebar-ordering problem in the ChatGPT/Codex desktop app on Windows.

Chats/sessions that previously appeared according to how recently they were being worked on no longer have an understandable order. A session that was started or actively worked on recently does not reliably move near the top, and it is unclear whether the current order is based on recency, creation time, priority, manual order, pin state, or stale cached data.

Expected behavior

  • The sidebar should use a stable, documented ordering, preferably most recently active first.
  • A chat/session should move appropriately when it receives new activity.
  • Pinning or unpinning should not leave the visible order stale.
  • If multiple ordering modes are supported, the selected mode should be visible and actually determine the list order.

This appears to be a related reproduction of the stale/incorrect sidebar ordering described in this issue.

Milad-Afdasta · 17 days ago

Additional local evidence for the sidebar ordering bug. I can reproduce the disorder without changing or deleting any conversations.

Observed

  • The local Codex SQLite state has no pinned or archived threads involved.
  • A fresh list_threads response returned an older-updated thread before a newer-updated thread:
  • Thread A: updatedAt=1786329870
  • Thread B: updatedAt=1786339145
  • The persisted rows explain the inversion:
  • Thread A: updated_at_ms=1786329870704, recency_at_ms=1786328482295
  • Thread B: updated_at_ms=1786339145266, recency_at_ms=1786328099811
  • The returned order follows the older recency_at_ms values, not newest updated_at_ms activity. The difference is hours, so this is not a timestamp tie.

Expected

For the normal unpinned conversation list, newest conversation activity should appear first, with a deterministic ID tie-breaker.

Suggested fix

Confirm the intended semantic owner for sidebar ordering. If “latest” means latest conversation activity, update the recency key whenever that activity changes or order the list by updated_at_ms DESC, id DESC. Add a regression test where updated_at_ms and recency_at_ms diverge, and assert that the visible/list order matches the documented user-facing meaning.

No local state was modified; this report is based on read-only SQLite and list_threads observations.

flodlc · 14 days ago

Same issue here on last version on MacOs. It totally destroys the work experience.

boombx403-byte · 9 days ago

Hi @caichutian, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.