Skip to content

Codex App: add manual refresh button (or auto-sync) for archived and cross-surface conversations #11907

Open
Open
Codex App: add manual refresh button (or auto-sync) for archived and cross-surface conversations#11907
Labels
appIssues related to the Codex desktop appenhancementNew feature or request

Description

@gydx6
gydx6
opened on Feb 16, 2026

Summary

The macOS app has multiple refresh/sync gaps:

  • cross-surface sync behaves differently between VS Code extension and CLI
  • conversation list does not refresh correctly after restoring a thread from Archive inside the app

Observed behavior

macOS app state Where conversation is created/continued Actual behavior
App is already open Restore a conversation from Archive in macOS app Restored conversation does not appear in the active list until app restart
App is already open Create a new conversation in VS Code extension New conversation does not appear in app
App is already open Create a new conversation in CLI New conversation does not appear in app
App is opened after conversation was created in VS Code extension Continue chatting in VS Code extension App can see the conversation and continues to receive new turns (works)
App is opened after conversation was created in CLI Continue chatting in CLI App can see the conversation entry, but new CLI turns do not refresh in app

Expected behavior

  • Restoring a conversation from Archive should immediately update the active conversation list in the macOS app.
  • The macOS app should discover newly created conversations from both VS Code extension and CLI while the app is open.
  • After opening the app, new turns from both VS Code extension and CLI should keep syncing consistently.
  • A visible Refresh button in the app would be a useful fallback when real-time sync misses updates.

Repro steps

Case A: restore from Archive inside app

  1. Open the macOS app.
  2. Go to Archive and move one archived conversation back to active.
  3. Return to the active conversation list.
  4. The restored conversation does not appear until app restart.

Case B: app already open (new conversation from CLI/VS Code)

  1. Open the macOS app.
  2. Create a new conversation in CLI (or VS Code extension).
  3. Check the app conversation list.
  4. New conversation is not shown.

Case C: app opened later (VS Code path)

  1. Create a new conversation in VS Code extension.
  2. Open the macOS app.
  3. Continue chatting in VS Code extension.
  4. App receives new turns (works).

Case D: app opened later (CLI path)

  1. Create a new conversation in CLI.
  2. Open the macOS app.
  3. Continue chatting in CLI.
  4. App does not refresh newly added CLI turns.

Environment

  • Codex App version: 26.212.1823 (build 661)
  • macOS: 26.3 (build 25D125)

Related issues

Activity

  1. github-actions
    added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    on Feb 16, 2026

  2. nilswx commented on Feb 16, 2026

    @nilswx
    nilswx
    on Feb 16, 2026

    Related: programmatically managing threads via MCP or codex app-server (thread/start, turn/start) also requires a restart before Codex.app (or other sources) will show/bump the thread, even if filters match.

    Codex.app ships (and runs) its own codex binary, but this is definitely something to synchronize between surfaces for every $CODEX_HOME/config.toml universe.

  3. slobodanmargetic988 commented on Feb 23, 2026

    @slobodanmargetic988
    slobodanmargetic988
    on Feb 23, 2026

    Minimally switching to a thread in the app itself should trigger an attempt to reload if thread is changed later than the last change the app sees.
    Idealy app should be able to track background executions and show spinning icon when the tread is working in the background. This would let us have a smooth looking automation workflow. Right now an orchestrator thread dispatching background threads doesnt let us see what the background threads are doing in real time. And that is the real automation powerhouse.

  4. cixiangtao commented on Aug 6, 2026

    @cixiangtao
    cixiangtao
    on Aug 6, 2026

    Adding a current reproduction where this is more than a missing refresh action: the same conversation has persistently different visible turn history across the desktop client and VS Code extension.

    Environment

    • Desktop: ChatGPT/Codex app 26.730.61639 (com.openai.codex, build 6234)
    • IDE: VS Code 1.131.0 (arm64)
    • Codex IDE extension: openai.chatgpt@26.727.40816
    • OS: macOS 15.7 (arm64)

    Observed behavior

    • The same conversation can show different history in the desktop client and the VS Code extension.
    • Missing synchronization can happen in both directions.
    • The more common direction is VS Code extension -> desktop: the desktop client is missing the latest several turns that are visible in the extension.
    • Quitting and restarting the desktop client does not restore those missing turns.
    • The VS Code restart/recovery direction has not yet been tested reliably.

    This appears to be persistent cross-surface thread hydration/state divergence, not only a delayed conversation-list refresh.

    Impact

    Users cannot determine which surface contains the authoritative transcript. Continuing from the stale surface can cause requests to be repeated, omit recent decisions, or make the user act on an outdated understanding of what Codex already executed. For an agent that can edit files and run commands, the same thread must have a trustworthy and auditable history on every supported surface.

    Expected behavior

    • A conversation ID should resolve to the same ordered and complete set of persisted turns in both surfaces.
    • Reopening either surface should rehydrate the canonical thread state and repair missed events.
    • If synchronization cannot be completed, the UI should show a clear stale/out-of-sync warning rather than silently presenting an incomplete transcript.
    • A manual refresh action is useful as a fallback, but durable canonical rehydration is required.

    Please treat this as a correctness/reliability bug rather than only an enhancement request.

  5. mikejurka commented on Aug 11, 2026

    @mikejurka
    mikejurka
    on Aug 11, 2026

    I can also reproduce this specifically with CLI → ChatGPT Desktop archive sync. But as the original bug states, I think this is just one example of the greater issue of sync.

    1. Archive a thread from CLI:
    codex archive 019f52b0-0c01-70c3-95fd-16e4449ed9d4
    1. CLI confirms it was archived.
    2. In the already-open ChatGPT Desktop app, the thread still appears active in the sidebar.
    3. Clicking it gives:
    Failed to resume chat
session ... is archived

    Restarting ChatGPT Desktop fixes the sidebar state.

    So the archive succeeds, but Desktop does not refresh/reconcile the thread list after an external CLI archive. This looks like the CLI → Desktop version of the cross-surface refresh bug.

  6. anandx commented on Aug 18, 2026

    @anandx
    anandx
    on Aug 18, 2026

    We found a working workaround (but please fix this 🙏🏾) in verified with the Desktop-bundled Codex runtime 0.147.0-alpha.6.5.

    After a private app-server successfully archives or unarchives a thread, we publish the same lifecycle broadcast used by Desktop over ~/.codex/ipc/ipc.sock:

    • thread-archived v2 with hostId, conversationId, and cwd
    • thread-unarchived v1 with hostId and conversationId

    Desktop then refreshes immediately without restarting. When a shared app-server daemon is available, routing the mutation through that instance also propagates the update.

    This is an undocumented, best-effort workaround and only covers events observed while connected. A supported cross-client lifecycle invalidation—or simply refreshing thread/list when history/archive opens—would remove the need for it.

  7. newjoy commented on Sep 13, 2026

    @newjoy
    newjoy
    on Sep 13, 2026

    Reproduced the unarchive direction of this cross-surface synchronization issue on September 13, 2026.

    Environment

    • ChatGPT desktop app, Codex surface, macOS
    • Desktop version: 26.908.40834, build 8881
    • Bundled CLI: codex-cli 0.154.0-alpha.6.2
    • macOS: 15.3 (24D60)
    • Same local account and default Codex home; no manual edits to session storage or the client database

    Minimal reproduction

    1. Keep the desktop app running and use an existing, idle local task.

    2. Archive that task through the desktop's built-in task tool.

    3. In a separate process, run the bundled official CLI:

      /Applications/ChatGPT.app/Contents/Resources/codex unarchive <thread-id>

    4. CLI exits 0 and prints: Unarchived session <title> ().

    5. The running desktop still does not show the task in its project/sidebar.

    6. Repeating the CLI command exits 1 with: Error: failed to unarchive session. It does not refresh the desktop.

    Independent app-server reproduction and positive control

    • A separate official app-server's thread/unarchive also successfully restores the original task.
    • thread/resume on the same ID and a read-only pwd turn succeed; original cwd/history remain available.
    • After that process exits, the desktop's read tool can read the completed turn, but opening the task page still shows it as archived.
    • Desktop unarchive then fails with: no archived rollout found for thread id .
    • The user reproduced the stale state twice and confirmed restarting the desktop restores visibility.
    • Positive control: archive AND unarchive both through the desktop's built-in task tools return success and immediately restore visible sidebar state without restarting. The user confirmed this separately.

    Expected behavior and impact

    The desktop should reconcile a successful external CLI/app-server unarchive with canonical task state without requiring a full app restart. Opening the task or archived list should recover missed lifecycle changes, or a supported refresh/invalidation API should be available.

    This blocks reliable same-task handoff to an event-driven local integration while allowing the user to keep the desktop open for other tasks. No new/forked task was used as a substitute, and the minimal CLI reproduction does not depend on our integration or a model call.

    This looks related to #33860's stale UI symptoms, but our initial independent unarchive returns success, not the initial failed-to-read-unarchived-thread error. We have not established the internal root cause and have not injected private IPC notifications or modified the client database.

    No real task IDs, task titles, repository paths, credentials, or transcripts are included in this report.

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 appenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions