Active Codex Desktop thread is not visible in sidebar despite being unarchived and recently updated #30644

Summary

An active Codex Desktop chat session is not visible or is very hard to find in the left sidebar, even though the underlying thread row exists locally, is not archived, and continues to receive updates.

The confusing part is that the active conversation appears to be a resumed older thread. The sidebar-visible metadata remains anchored to the original first message/title from May, while the current conversation is happening on June 30. The thread also has has_user_event=0, which may be causing the sidebar to omit it depending on the current filtering/indexing logic.

Environment

• macOS Codex Desktop
• bundled CLI: codex-cli 0.142.4
• Local state DB: ~/.codex/state_5.sqlite
• Current active thread id observed via environment: 019e40ad...2390 (redacted)

Expected behavior

The currently open/active chat session should be visible in the left sidebar, especially when:

• it is not archived;
• it has recent user/assistant activity;
• its updated_at / recency_at are current;
• the user is actively interacting with it in the main chat surface.

The sidebar title/preview should also reflect recent conversation context enough for the user to identify the thread, or at least the active thread should not disappear from the list.

Actual behavior

The active chat session is not visible in the left sidebar under the current/recent conversation title. The user could not find the session in the sidebar even while actively chatting in it.

Local inspection shows that the thread exists and is not archived, but the title/preview are still from the old first message of a session that began on May 19. Meanwhile updated_at and recency_at are current for June 30.

Evidence

The active session id was available in the environment:

CODEX_THREAD_ID=019e40ad...2390

The corresponding thread row exists in ~/.codex/state_5.sqlite:

id:             019e40ad...2390
archived:       0
has_user_event: 0
updated:        2026-06-30 10:40:11
recency:        2026-06-30 10:39:55
title:          <old first message from May 19 remote-control debugging session>
preview:        <same old first message from May 19 remote-control debugging session>

Important observations:

• archived = 0, so this is not hidden because it is archived.
• updated_at and recency_at are current, so the thread is actively receiving activity.
• has_user_event = 0 despite the user actively sending messages in the thread.
• title and preview remain the initial May 19 message, not the current June 30 conversation context.

A query ordered by recency_at DESC shows the active thread at the top of the DB results, but the user could not find it in the app sidebar:

SELECT id, archived, has_user_event,
       datetime(updated_at,'unixepoch','localtime') AS updated,
       datetime(recency_at,'unixepoch','localtime') AS recency,
       title
FROM threads
ORDER BY recency_at DESC
LIMIT 25;

The active row appears first in this query, but still does not appear as expected in the visible sidebar.

Suspected problem

There may be a mismatch between the live active thread and the sidebar's thread-list/indexing criteria. In particular:

1. The active thread can have has_user_event=0 even after current user messages.
2. The sidebar may filter out has_user_event=0 rows.
3. A resumed/continued older thread can keep stale title/preview metadata, making the current session unfindable even if the row is technically present.
4. The active thread's recency metadata updates, but the sidebar may not reconcile or render it consistently.

Impact

Users can lose track of an active conversation from the sidebar. This is especially confusing for long-running debugging sessions because the open chat exists and continues to update, but it cannot be found by its current topic/title in the conversation list.

Requested improvements

1. Ensure the currently active thread is always visible in the sidebar when not archived.
2. Recompute or update has_user_event when the user sends messages in a resumed thread.
3. Refresh sidebar title/preview for resumed threads so they are identifiable by recent context.
4. If the sidebar intentionally filters has_user_event=0, avoid assigning that state to live user-visible conversations with recent user activity.