macOS Desktop 26.715.31925: model selector disappears and prompts stop sending after switching between 2-3 chats
Summary
In the macOS ChatGPT/Codex desktop app, the model selector disappears from the composer after switching between approximately 2-3 existing chats. Once the selector disappears, prompts can no longer be sent reliably. Fully quitting the app with Cmd+Q and reopening it temporarily restores the composer.
A clean reinstall and a fresh UI profile did not resolve the issue.
Environment
- ChatGPT/Codex Desktop:
26.715.31925(CFBundleVersion5551) - Bundled app-server:
0.145.0-alpha.18 - macOS:
26.5.2(build25F84) - Architecture: Apple Silicon / arm64
- Account and model catalog load successfully
- Local SQLite integrity checks return
ok
Steps to reproduce
- Launch the macOS desktop app in Codex.
- Open an existing chat.
- Switch between 2-3 existing chats.
- Observe that some
thread/resumeoperations become increasingly slow. - Return to a chat and inspect the composer.
Actual behavior
- The model selector disappears from the message composer.
- Sending a prompt becomes unavailable or unreliable.
- The app itself remains open and the sidebar/history remain present.
- Cmd+Q followed by relaunch temporarily restores the selector.
- The issue returns after switching between chats again.
Expected behavior
The composer should retain the selected model and remain able to send prompts after switching between chats.
Relevant diagnostics
At the exact time of reproduction, the desktop log showed:
method=account/read ... errorCode=null
method=config/read ... errorCode=null
method=thread/resume ... durationMs=7916 ... errorCode=null
method=thread/resume ... durationMs=11665 ... errorCode=null
[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
Earlier reproductions in the same build also logged:
Received turn/started for unknown conversation
Received turn/completed for unknown conversation
The model cache remains populated and includes the expected models, so this appears to be a renderer/composer state desynchronization during thread resume rather than model availability or authentication failure.
Additional notes
- Reinstalling the application did not fix the issue.
- Resetting the Chromium/UI profile did not fix the issue.
- No third-party antivirus process is active.
- The problem is reproducible with local project chats.
- Full logs contain local paths and chat metadata, so they are not attached publicly, but a sanitized excerpt or diagnostics bundle can be provided if requested.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗