[macOS 26.930] Legacy ChatGPT projects lose local history after cold restart; sidebar fallback never starts local history pagination #50878

Environment

• ChatGPT desktop / Codex on macOS.
• Installed release: 26.930.31730, build 12947, production channel.
• The configured updater reports up_to_date on October 4, 2026.
• Existing ChatGPT projects have legacy g-p-* local mirror records and saved local thread assignments.

User-visible failure

Original project folders remain visible but show “No chats” after fully quitting and reopening the application. The underlying local conversations, transcripts, directories, and saved legacy project assignments are still present.

This report focuses on legacy ChatGPT project folders. Ordinary local folder projects have a separate loading path and are not assumed to have the same defect.

Observed sequence

1. Cold-start the desktop application and expand an existing legacy ChatGPT project containing local historical conversations.
2. The original project displays no chats.
3. Load those same original conversations through a custom sidebar section, then return them to their default placement. The original project now displays the historical conversations. The user confirmed all six conversations in one project, and history in two additional original projects.
4. Fully quit and restart. The original project history disappears again.
5. Keep the six conversations in a custom section instead. The user confirmed that this section still exposes the six conversations after restart.

The section workaround restores access but does not meet the requirement that history remain visible in the original project.

Read-only findings

• In two sampled legacy projects, the desktop catalog contains all 6 and 38 expected local conversation records, respectively.
• The legacy project records, project roots, and saved thread assignments are present.
• The installed legacy project-row component merges supplied, already-loaded local thread keys with cloud conversations. It does not subscribe to a local project catalog page or initiate local pagination.
• A different, linked-project component does subscribe to the local project catalog and supports loading additional local pages.
• The legacy branch is selected when there is no enabled linked local project ID.
• Startup loading is bounded. In both sampled projects, no matching assignment occurs in the first 100 assignment entries inspected by the selected-project seed loop. This is an additional observation, not a claim that changing that loop alone is sufficient.
• Opening the original project's normal “New local chat” entry, without sending a message, updated the legacy record but did not establish a newer native/cloud project association.

The live values of rollout gates were not captured. No claim is made that a particular disabled gate has been proved to be the root cause.

Isolated reproduction and candidate direction

An isolated harness uses the installed legacy row component and installed local-page subscription callback, with synthetic project/thread IDs, stubbed render primitives, and a fake catalog reader:

• Empty initial local keys: original component displays zero local rows and initiates zero local page queries.
• Supply six preloaded local keys: original component displays six local rows.
• New fixture with empty keys: original behavior returns to zero rows and zero local queries.
• Candidate wrapper subscribes to the existing legacy-project local catalog scope. On each fresh fixture it calls the existing page loader for six entries (five visible plus lookahead), retains a load-more operation, and renders the six keys after the ordinary catalog update.

These checks passed. They are a component-level reproduction, not a complete desktop startup test or an installed fix. The application bundle was not modified.

Please give legacy project rows their own local-catalog subscription and pagination, using existing assignment, root, pinned-item, section, host and account filtering. Do not depend on unrelated views preloading the history, or require users to recreate projects.

Changes already tried and limits

• Chronological sorting did not resolve the issue.
• A six-conversation trial using valid backend project IDs did not fix the observed UI and was reverted; a cold restart with that trial still applied was not performed.
• Custom sections are a confirmed access workaround for the six-conversation restart test.
• Original titles, working directories, archive flags, legacy assignments and transcript paths were checked and preserved.

Required acceptance

• Original legacy project folders load their local history after a cold start without first opening a conversation or custom section.
• Larger projects paginate beyond the initial visible rows.
• Cold restart, project switching, and collapsing/re-expanding do not lose the list.
• Existing project identities, local files, titles, assignments, pinned conversations and archives remain intact.
• No duplicate projects or permanent workaround sections are required.

Privacy

Project and conversation names/IDs, personal filesystem paths, account identifiers, credentials, raw logs, screenshots, transcripts, and proprietary source excerpts are omitted from this public report.