Repository navigation
[macOS][Chat] Desktop app goes offline; valid conversations fail to load while iOS works #49170
Description
Summary
The unified ChatGPT desktop app on macOS is intermittently becoming unusable in the Chat surface while the same account and conversations continue to work normally in the ChatGPT iOS app.
The failure presents as a mix of connection, account-state, and conversation-loading problems in the desktop app.
Subscription
- ChatGPT Plus
Platform
- macOS desktop app
- Apple Silicon Mac
- Same account simultaneously tested in ChatGPT iOS
- Network retested over 5G / phone hotspot
Actual behavior
During the incident on 2026-09-29 JST, the macOS desktop app showed several recurring symptoms:
- Bottom-left status changed to Offline even though the Mac had working internet access.
- The account/profile UI partially lost its normal state/appearance.
- Recent chats and project contents sometimes disappeared or failed to populate.
- Existing conversations remained visible in the sidebar, but opening one showed:
- “Could not load this ChatGPT conversation” / Japanese equivalent: 「このChatGPTの会話を読み込めませんでした」.
- New messages could be typed into the composer but sending did not progress.
- The app sometimes became fully unresponsive / frozen.
- Reconnection/loading spinners appeared repeatedly.
- Codex functionality could still work at times while the ordinary ChatGPT Chat surface was broken.
Cross-client comparison
At the same time, the ChatGPT iOS app on the same account could open and continue the exact same conversation normally.
This strongly suggests the conversation still exists server-side and the account itself is valid; the failure appears specific to the macOS desktop client or its desktop session/synchronization path.
Troubleshooting already attempted
- Fully quit and relaunched the desktop app 4 times.
- Switched/tested network connectivity using 5G / phone hotspot.
- Confirmed the iOS app remained functional on the same account and could access the same conversation.
- Confirmed the desktop app could sometimes repopulate the sidebar after relaunch, but selecting the conversation still failed to load it.
The problem recurred after relaunches.
Reproduction pattern
The issue is intermittent, but the observed sequence was roughly:
- Use ChatGPT/Codex desktop normally.
- Desktop enters a reconnecting/offline state.
- Relaunch the app.
- Sidebar/account UI may partially recover.
- Select a known-good ChatGPT conversation that is currently open and usable on iOS.
- Desktop displays “Could not load this ChatGPT conversation.”
- Attempts to start/send a new chat may also stall.
- The desktop app may freeze or return to an offline/reconnecting state.
Expected behavior
- If the Mac has working internet access, the desktop app should not enter a persistent false-offline state.
- Account/profile UI should remain synchronized.
- A conversation that is valid and currently usable on iOS should open normally on macOS desktop.
- New messages should send normally.
- The app should recover cleanly from transient reconnects without repeated relaunches.
Additional notes
This does not appear to be a deleted/ghost-conversation case: the same conversation remains valid and actively usable on iOS while the macOS desktop app reports that it cannot load it.
Screenshots captured during the incident show:
- the desktop app explicitly displaying Offline;
- the same valid conversation present in Recents but failing with “Could not load this ChatGPT conversation”;
- partial account/profile UI state during the failure.
I can provide additional sanitized diagnostics if maintainers need them.
Activity
github-actions commentedon Sep 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
lpomjnuge-netizen commentedon Sep 29, 2026
Update during the same incident: the macOS desktop app's account/profile UI has partially recovered, but conversation history / thread hydration is still broken. Existing chats remain unable to load, so normal ChatGPT work is still effectively blocked on desktop even though the account indicator now looks normal again. iOS continues to work with the same account/conversations. This suggests the failure can partially recover at the account/UI layer while the conversation-loading path remains stuck.
lpomjnuge-netizen commentedon Sep 29, 2026
Additional observation after re-authentication: the Plus subscription badge returned, but the ordinary ChatGPT Chat conversations disappeared from the desktop app entirely. Only Codex conversations remain visible. The same normal ChatGPT conversations are still present and usable on iOS and on chatgpt.com with the same account. This further isolates the failure to the macOS unified desktop app's Chat conversation index/synchronization or hydration path, rather than account loss or deleted conversations.
lpomjnuge-netizen commentedon Sep 29, 2026
Further clarification: the failure is not limited to history rendering. On the macOS desktop app, the ordinary ChatGPT Chat surface is effectively unusable: I can type a message and press Enter, but nothing progresses afterward. At the same time, Codex conversations still work in the same desktop app. This creates a clear split where the Codex surface remains functional while the normal Chat surface cannot send or load conversations. Web and iOS ChatGPT remain usable with the same account.
pvillavi commentedon Oct 17, 2026
Also affected on October 17: ordinary ChatGPT conversations failed to load on Mac/web while the same chats worked on iOS. Some conversations later recovered, but full recovery remains unverified. Related report: #48393 (comment). Is there a confirmed fix or supported workaround?
pvillavi commentedon Oct 17, 2026
Additional observation on October 17 at 20:23 UTC: the conversation page loaded but displayed ‘Conexión interrumpida. Esperando la respuesta completa.’ (‘Connection interrupted. Waiting for the complete response.’), with Stop still visible. A subsequent reload timed out. I could not verify whether generation was actually active or safely submit the next instruction. This is partial UI access, not confirmed recovery; no data loss or HTTP cause has been established.