›_ Codex Issues
Codex Issues / #11907

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

Open 💬 5 comments Opened Feb 16, 2026 by gydx6

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

  • #5609
  • #2153

View original on GitHub ↗

5 Comments

nilswx · 6 months ago

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.

slobodanmargetic988 · 6 months ago

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.

cixiangtao · 22 days ago

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.

mikejurka · 16 days ago

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.

anandx · 9 days ago

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.