Skip to content

macOS 26.930: chats disappear inside project groups while saved assignments remain; API returns null membership #51477

Open

Description

@PandaKingK

Desktop regression: existing local chats intermittently disappear from project sidebar

Environment

  • macOS; ChatGPT desktop app with local Codex chats
  • Installed desktop version: 26.930.61225, build 13232
  • Observed on 2026-10-06
  • Project grouping on the Work surface; chats sorted by updated time
  • Existing ChatGPT-backed projects represented by legacy g-p-* project IDs

Actual behavior

After a desktop update, multiple existing local chats disappeared from their expanded project groups. The issue affected at least two projects. An expanded project displayed only three chats and no load-more control, although 17 active local chats were recorded with that project's legacy assignment.

The chats remained readable through direct thread access and were not archived. This appears to affect discovery/project display rather than confirmed loss of conversation content.

The problem recurred during the investigation. After supported sidebar operations and catalog reads, the user reported that the project chats were visible again. A reliable single-action workaround or deterministic reproduction has not been established.

Concrete evidence

  1. For two sampled chats, the supported list_threads response returned projectId: null while the local thread-project-assignments setting still contained an explicit local project assignment for the same thread. One sample belonged to each affected project.

  2. local_thread_catalog.project_id was NULL for both sampled chats. NULL catalog project IDs also occur for visible chats, so this is diagnostic context, not independent proof of the root cause.

  3. Local settings recorded projectsMigrated: true and threadAssignmentsMigrated: false with pending thread assignments. The installed code gates assignment migration on a feature flag, so an incomplete flag alone must not be treated as a proven failed migration.

  4. Startup logs on the same day contained:

    2026-10-06T05:22:15.990Z info [host-app-server-projects] Local app-server project migration completed projectCount=17
    2026-10-06T05:24:14.223Z info [host-app-server-projects] Local app-server project migration completed projectCount=17
    
  5. As a separate observation, five chats were pinned through the supported API and confirmed in a following read. A later read returned the original ten pins without those five. Re-pinning them and reading back restored the five. This may be a related state persistence issue, but the user's main issue is project groups, not pinned chats.

Expected behavior

All non-archived local chats explicitly assigned to a project remain discoverable in that project's sidebar group across updates and normal navigation. If pagination is required, the group exposes a working load-more control. Supported operations and subsequent catalog reads agree on project membership.

Investigation steps / reproduction guidance

  1. Use an upgraded desktop profile with existing ChatGPT-backed project IDs and local chats explicitly assigned through legacy settings.
  2. Expand an affected project group and compare displayed entries with active saved assignments. Do not assume absence means archiving.
  3. Compare list_threads.projectId, legacy thread-project-assignments, native thread/project metadata and catalog membership for the same chats.
  4. Check whether membership resolution changes after normal navigation or a supported sidebar state write. In this incident, several interventions preceded recovery, so the precise trigger is unknown.
  5. Verify that pin and membership state survive subsequent reads and normal application activity.

Suspected area, not proven root cause

Project-membership resolution, migration or state invalidation between legacy assignments, the local catalog and the sidebar's combined project sources. Investigate why an explicit saved assignment can resolve to null and why a project scope can show a partial list without a load-more control.

No internal databases or migration flags were edited, no chats were deleted, and no conversations were sent new prompts as part of diagnosis. Read-only database/settings inspections and supported app operations were used. Project grouping was toggled, existing chats were opened and pins were changed; these actions prevent attributing recovery to a single operation.

Related reports

This incident concerns missing chats inside project groups that remain visible, plus a mismatch between explicit saved membership and API output. Shared root cause is unconfirmed.

Submitted by an AI assistant at the user's explicit request. This public report omits private chat contents, project names, identifiers and paths.

Follow-up: third affected project

The user also reported many missing chats inside a third project group. Read-only inspection found 25 active local chats with explicit saved membership in this third project. The full sidebar visibility was not independently measurable through the available API, whose non-pinned result limit is 50 globally. All 25 were navigated to through the supported app interface to refresh access; this does not establish a durable sidebar repair. This extends the reported scope beyond the first two projects. Private names, chat titles and identifiers remain omitted.

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 appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions