Skip to content

Codex Desktop left sidebar only shows ~50 conversations, making older project chats disappear #25761

Open

Description

@GGBondBlueWhale

What version of the Codex App are you using?

26.527.60818 (3437)

What platform is your computer?

  • macOS Tahoe 26.5
  • Apple Silicon MacBook Pro

What issue are you seeing?

Codex Desktop's left sidebar appears to have a hard visibility limit of about 50 chat/conversation entries. Once more conversations are created, older conversations disappear from the sidebar, especially under projects that have not been used for a while.

I discovered this because several of my long-running projects started showing fewer and fewer conversations over time. At first it looked like project chat history was being lost or removed. After counting the visible entries in the left sidebar, it appears that the sidebar can only display around 50 conversations total.

This issue has existed for a very long time across Codex Desktop versions and still appears to be reproducible on my current build.

Why this is a serious problem

This is a major workflow bug, not just a cosmetic UI problem. Codex project conversations are often used as the working memory for long-running development tasks. They contain debugging history, implementation decisions, prior instructions, and context needed to continue work.

When older conversations silently disappear from the project sidebar, it creates the impression that previous work history has been deleted or lost. It also makes older conversations very difficult or impossible to find from the Desktop UI. This causes serious disruption to my workflow because past project context becomes unavailable after enough newer conversations are created.

Steps to reproduce

  1. Use Codex Desktop with multiple projects and many conversations.
  2. Create more than about 50 conversations over time.
  3. Stop using one or more projects for a while.
  4. Open Codex Desktop and inspect the left sidebar/project conversation list.
  5. Older project conversations are no longer visible, and project history appears to shrink or disappear.

Expected behavior

  • The project sidebar should not hide older valid conversations just because they are outside a global recent-chat window.
  • Expanding/opening a project should load or paginate that project's full saved conversation history.
  • Sidebar search should be able to find older saved conversations, not only the currently visible/recent subset.
  • The UI should clearly distinguish between "no chats" and "older chats not loaded yet".
  • If there is a temporary performance limit, there should be a visible "Load more" or pagination mechanism.

Actual behavior

  • The left sidebar appears to only show around 50 conversations.
  • Older project conversations silently disappear from the UI as newer conversations are created.
  • Projects that have not been used recently gradually appear to lose their conversation history.
  • Users may believe their historical Codex work has been lost.

Please prioritize a real fix for the sidebar/project history loading logic. Simply increasing the fixed number from 50 to another small limit would not fully solve the issue; the Desktop UI needs a reliable way to load and search persisted project conversation history.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jun 2, 2026
  2. ashe0047 commented on Jun 6, 2026

    @ashe0047

    Please bump this issue up in terms of fix priority since it is really affecting the overall usage experience of Codex

  3. dperetti commented on Jun 9, 2026

    @dperetti

    This is REALLY annoying.

  4. smartLanny commented on Aug 25, 2026

    @smartLanny

    Adding a macOS data point that makes the current approximately 50-thread limit especially risky for project cleanup and archiving.

    Environment:

    • ChatGPT desktop app / Codex: 26.818.61809
    • macOS 27.0 (26A5416b)

    Observed behavior:

    1. The active task-list interface rejects a request above 50 non-pinned threads.
    2. The local authoritative thread database contains many more valid, non-archived threads than the Recents window exposes.
    3. Once every visible chat for an older project falls outside that window, the project appears empty even though older assigned chats still exist.
    4. Because those chats are not rendered inside the project, the user has no visible way to inspect or bulk-archive them before removing the apparently empty project.

    The removal semantics are important here: local-state inspection shows that project membership and archival are independent. The thread schema stores an archived flag separately from project_id, and deleting a project uses ON DELETE SET NULL for threads.project_id. Therefore, users should not assume that removing an apparently empty project automatically archives its hidden chats. It can instead leave them unarchived and projectless, outside the normal Recents view.

    A recent sanitized test also confirmed the safe-but-incomplete workaround:

    • First use the project menu's Archive chats action.
    • Then remove the empty project.
    • Three chats from that project remained archived, but all three lost their explicit project association (project_id = NULL) and retained only a common recorded working directory.

    Requested fixes for this issue:

    • Project views should paginate/load their complete saved chat history independently of the global Recents limit.
    • Archive chats must operate on every chat assigned to the project, not only currently loaded/rendered chats.
    • An empty state must distinguish No chats exist from Older chats are not loaded.
    • Removing a project must warn when hidden chats are still assigned and clearly state that removal is not archival.
    • Search and a full-history view must remain able to recover chats outside Recents.

    I filed #40667 for the complementary project-lifecycle feature: archive a project as a unit, hide it from the active sidebar, preserve its thread grouping, and restore it later.

  5. zhzLuke96 commented on Oct 6, 2026

    @zhzLuke96

    I am really confused; I completely fail to understand why it was designed this way.

    至少给我们一个可以配置的地方吧...历史session很重要啊,莫名其妙丢失很影响工作效率

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions