Skip to content

Codex Desktop (Windows): UI-archived conversations reappear in active sidebar after refresh, and archive triggers flashing terminal cleanup #25541

Open

Description

@biggameking

What version of the Codex App are you using (From "About Codex" dialog)?

Observed on a Windows desktop install whose shipped frontend bundle is:

  • openai.chatgpt-26.325.31654-win32-x64

Affected local bundle paths:

  • C:\Users\q1371\.antigravity\extensions\openai.chatgpt-26.325.31654-win32-x64\webview\assets\app-server-manager-hooks-XL0eRatK.js
  • C:\Users\q1371\.antigravity-ide\extensions\openai.chatgpt-26.325.31654-win32-x64\webview\assets\app-server-manager-hooks-XL0eRatK.js

What subscription do you have?

Pro / paid account context on the reporting machine.

What platform is your computer?

Windows 11 x64

What issue are you seeing?

Archiving conversations from the official Codex Desktop sidebar appears to succeed briefly, but after a later refresh / reconciliation cycle the archived conversations reappear in the active sidebar list.

At the same time, the archive action on Windows frequently causes visible flashing terminal windows, which strongly suggests that the archive UI path is dispatching unnecessary worktree cleanup during archive.

This is not just a one-off local DB inconsistency or a direct-SQL repro. The problem reproduces when the user archives threads through the normal Desktop UI, then waits for the app to refresh/reconcile its recent-thread list.

What steps can reproduce the bug?

  1. Open Codex Desktop on Windows with many existing local conversations in the sidebar.
  2. Archive multiple conversations from the normal sidebar UI.
  3. Confirm they disappear initially.
  4. Keep using the app or wait for the next refresh/reconciliation pass.
  5. Observe that the previously archived conversations reappear in the active sidebar list.
  6. During archive operations, observe frequent short-lived flashing terminal windows on Windows.

What is the expected behavior?

  1. A conversation archived from the Desktop UI should remain hidden from the active sidebar list after refresh/reconciliation unless the user explicitly unarchives it.
  2. Archiving should not trigger visible terminal flashes or unrelated worktree cleanup on Windows.

Additional information

I inspected the shipped desktop frontend bundle and found two likely client-side causes.

1. Archive UI dispatch defaults cleanupWorktree to true

The shipped bundle contains logic equivalent to:

function gp(e,t={}){return t.cleanupWorktree!==!1&&(e==null||lp(e.source)==null)}
...
dispatchMessage("archive-thread", {
  hostId,
  conversationId,
  cwd,
  cleanupWorktree: r.cleanupWorktree !== false,
})

This matches the Windows symptom where archiving causes visible flashing terminal windows. In a local hotfix, forcing cleanupWorktree: false stopped that flashing behavior.

2. The frontend maintains archive suppression state, but recent-sidebar readers do not consistently honor it after refresh

The same bundle maintains a local set named:

suppressedArchivedConversationIds

However, the recent/sidebar read paths rebuild from recentConversationIds and do not consistently filter archived-suppressed IDs when rendering recent conversations and related derived state.

The most relevant readers are equivalent to:

  • getRecentConversations()
  • getRecentConversationCwds()
  • getUnreadLocalConversationCount()
  • getHasInProgressLocalConversation()

In a local hotfix, filtering these readers by suppressedArchivedConversationIds.has(conversationId) prevented archived conversations from reappearing in the active sidebar after refresh.

Why this issue is likely related to, but distinct from, existing reports

  • Related to #23851, which reports archive state being reset during reconciliation. That report uses a direct DB repro; this report confirms that the same family of problem is reachable through the official Desktop UI archive flow.
  • Related to #20317 and several other archive/session/sidebar bugs, but this specific report adds a deterministic frontend-side explanation for both:
    • archived threads reappearing in the active sidebar
    • archive causing terminal flashes on Windows

Suggested fix

  1. Do not default Desktop UI archive dispatches to cleanupWorktree: true.
  2. Ensure all recent/sidebar rendering and derived-state readers consistently exclude locally suppressed archived conversation IDs after archive succeeds.
  3. Add regression coverage for:
    • archive from Desktop UI, refresh sidebar, archived thread stays hidden
    • bulk archive from Desktop UI, refresh sidebar, archived threads stay hidden
    • archive on Windows does not trigger visible terminal cleanup windows

This looks like a Desktop frontend reconciliation bug rather than a machine-specific corruption issue.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jun 1, 2026
  2. github-actions commented on Jun 1, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  3. zaneperry commented on Aug 12, 2026

    @zaneperry

    Confirmed still reproducible on the current Windows ChatGPT desktop release:

    • Product: ChatGPT (Powered by Codex & OWL)
    • Version: 26.803.41515
    • Release shown in About: Aug 6, 2026
    • Platform: Windows

    Conversations archived through the normal UI continue to resurface in Recent. This matches the sidebar refresh/reconciliation behavior described in this report.

  4. GengDaPeng commented on Aug 13, 2026

    @GengDaPeng

    Confirming the same behavior on macOS:

    • macOS 26.5.2 (25F84)
    • ChatGPT/Codex Desktop 26.803.61601 (build 6396)
    • Embedded Codex: codex-cli 0.147.0-alpha.6.5

    Archiving local-project threads from the Desktop sidebar hides them initially, but they reappear after fully quitting and restarting the app. The affected threads are not pinned.

    This appears to be the same archive/reconciliation issue described here, now also reproducible on macOS.

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, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions