Codex Desktop: unpinned active thread disappears in “By project” sidebar but remains searchable

Open 💬 1 comment Opened Jul 19, 2026 by fujiwarakasei

Summary

In Codex Desktop, an active local thread disappears from the left sidebar immediately after it is unpinned when the sidebar is organized By project.

The thread is not deleted or archived:

  • Sidebar search still finds and opens it.
  • Pinning it makes it visible in the pinned section.
  • Unpinning it makes it disappear again.
  • Switching the sidebar organization to In one list makes it visible.
  • The app-server recent thread list includes it near the top.

This looks like a project-assignment migration/backfill bug rather than data loss or a recency/pagination issue.

Environment

  • Codex Desktop: 26.715.31925
  • Bundle version: 5551
  • Platform: macOS 26.5.2 (arm64)
  • Local threads
  • Sidebar organization: By project
  • Chat sort mode: priority

Steps to reproduce

  1. Use a local Codex project containing an existing active thread.
  2. Set Organize sidebar to By project.
  3. Find the affected thread through sidebar search and open it.
  4. Pin the thread.
  5. Confirm that it appears in the pinned section.
  6. Unpin the thread.
  7. Observe that it no longer appears anywhere in the project-grouped sidebar.
  8. Search for the same title; the thread is still returned and can be opened.
  9. Switch Organize sidebar to In one list; the thread becomes visible again.

Expected behavior

Unpinning an active thread should return it to its owning project group. Project grouping, the flat recent list, and search should agree on whether an active thread is discoverable.

Actual behavior

The active thread is hidden only by the project-grouped sidebar. Pinning, search, and the flat list continue to expose it.

Local evidence

The affected thread was inspected without modifying Codex state:

  • The row exists in ~/.codex/state_5.sqlite.
  • archived = 0.
  • Its rollout/session JSONL file exists.
  • Its updated_at is current.
  • SQLite integrity check passes.
  • thread/list(limit=50) returns the thread near the top of the normal recent list.
  • Its database cwd is inside a saved local project.
  • .codex-global-state.json has sidebar mode project.
  • The affected thread has no entry in thread-project-assignments.
  • It also has no entry in thread-workspace-root-hints.
  • It is not in projectless-thread-ids.
  • Once unpinned, it therefore appears to belong to neither a visible project group nor the projectless group.

Newer visible threads in the same project have explicit thread-project-assignments records. The affected thread predates the current local-project metadata/backfill, suggesting that the Projects migration did not assign every existing thread.

A bounded sibling check found 97 active threads whose database cwd is under the same saved project root, with many older threads also lacking explicit project assignments. This is therefore unlikely to be corruption of only one thread.

Suspected cause

The By project renderer appears to depend on project-assignment metadata that was not fully backfilled for older threads. Search, pinning, and In one list use paths that do not require the same assignment, which explains the visibility difference.

A safe automatic repair could derive or backfill the project assignment from a saved project root plus the thread's durable cwd, and provide a supported reindex/rebuild action.

Related issues

  • #27159
  • #25084
  • #10522
  • #14751
  • #19873

This report adds a deterministic pin/unpin reproduction on Codex Desktop 26.715.31925, plus the specific thread-project-assignments / thread-workspace-root-hints mismatch and the By project versus In one list behavior.

View original on GitHub ↗

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