Conversation thread jumps back into middle of sidebar when invoked from another thread

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

Description

Conversation threads do not remain ordered by recent user activity in the Codex conversation sidebar.

A newly created separate thread may initially appear in the middle of the conversation list instead of at the top. After the thread sends its first response, it moves to the top as expected. However, after opening that thread and then asking another thread to invoke or continue it, the invoked thread moves back into the middle of the list.

This makes active spawned threads difficult to find and can make it look like the thread disappeared or stopped running.

Steps to reproduce

  1. From an existing Codex conversation, ask Codex to start a new separate thread.
  2. Observe that the newly created thread appears somewhere in the middle of the conversation list rather than at the top.
  3. Wait for the new thread to send its first response.
  4. Observe that it now moves to the top of the conversation list.
  5. Open that thread.
  6. Switch to another thread and ask it to invoke, continue, or send work to the previously created thread.
  7. Observe that the invoked thread moves back into the middle of the conversation list.

Expected behavior

  • Creating a thread should count as recent activity and place it at or near the top immediately.
  • Invoking or assigning work to an existing thread should update its activity ordering and keep it near the top.
  • Active/working threads should remain easy to locate, ideally with a visible working state.

Actual behavior

  • A newly created thread can be inserted into the middle of the list.
  • Its first response moves it to the top.
  • Invoking it again from another thread can move it back into the middle.

Possible cause

The sidebar ordering may be based on inconsistent timestamps or activity fields across thread creation, assistant responses, direct opens, and cross-thread invocation. For example, one event may update lastActivity, while another restores or sorts using an older thread timestamp.

Impact

This is especially confusing when using multiple spawned agents or parallel threads because users must hunt through the conversation list to find currently active work.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 25 days ago

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

  • #36300

Powered by Codex Action

gertsio · 9 days ago

Same on macOS 26.5.2. Newly created thread lands at the bottom of the sidebar instead of the top, and overall ordering looks random after that.

One data point for the timestamp theory: my local ~/.codex/session_index.jsonl was healthy when this reproduced (1491 entries, updated_at strictly monotonic, zero out-of-order pairs), so the bad ordering is purely client-side, not local index corruption. I do not have the exact app build where it reproduced, I have since wiped app state and reinstalled (now on 26.814.41957). lmk if a repro on the new build with logs would help.