›_ Codex Issues
Codex Issues / #34255

macOS Desktop 26.715.31925: model selector disappears and prompts stop sending after switching between 2-3 chats

Open 💬 5 comments Opened Jul 20, 2026 by lalishka
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 (CFBundleVersion 5551)
  • Bundled app-server: 0.145.0-alpha.18
  • macOS: 26.5.2 (build 25F84)
  • Architecture: Apple Silicon / arm64
  • Account and model catalog load successfully
  • Local SQLite integrity checks return ok

Steps to reproduce

  1. Launch the macOS desktop app in Codex.
  2. Open an existing chat.
  3. Switch between 2-3 existing chats.
  4. Observe that some thread/resume operations become increasingly slow.
  5. 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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33524
  • #33242

Powered by Codex Action

lalishka · 1 month ago

I reviewed the suggested potential duplicates.

  • #33524 appears closely related at the underlying renderer/session level: it reports slow thread/resume, prompt submission freezes, ResizeObserver errors, and unknown-conversation events. However, it is a Windows report and does not describe the model selector disappearing.
  • #33242 is a macOS session-routing/resume issue with blank project chats, reconnection failures, and the same unknown-conversation events, but it is on an older build and likewise does not report the composer losing its model selector.

This report is likely in the same bug family, but I am keeping it open because it provides a distinct, consistently visible regression on current macOS build 26.715.31925: after switching between 2-3 chats, the model selector disappears and prompt submission becomes unavailable/unreliable while the model catalog and account remain healthy. Maintainers can close as a duplicate if one of those issues is confirmed to track this exact composer-state symptom.

webpot-ru · 1 month ago

Fresh reproduction after local project/worktree cleanup (Codex desktop 26.715.31925, macOS arm64):

  • The issue reproduced without opening the previously suspected large project.
  • model/list succeeded in 5 ms, so the backend model list was available.
  • Switching among three local chats triggered three concurrent thread/resume calls taking 24,793 ms, 27,119 ms, and 22,749 ms.
  • The same interval produced 45 thread/turns/list responses.
  • Immediately afterward the renderer logged repeated ResizeObserver loop completed with undelivered notifications errors.
  • turn/start still succeeded (60–257 ms), while the model selector disappeared and the composer stopped working in the UI.

This strongly suggests a desktop renderer/session-resume race or request storm rather than a repository size, antivirus, missing dependency, account, or model-service problem. Local SQLite integrity checks pass. Full app restart temporarily restores the UI, then the issue returns after switching 2–4 chats.

webpot-ru · 1 month ago

Additional reproducible trigger found on Codex Desktop 26.715.52143 (macOS 26.5.2 arm64):

  1. Start Codex normally; the model selector and message composer work.
  2. Open the Plugins page.
  3. Return to a chat.
  4. The model selector disappears and message sending may stop working until Codex is fully quit with Cmd+Q and restarted.

This reproduced even after Apps/widgets and browser feature flags were disabled in config, so it does not appear to require an enabled third-party plugin. Around the reproduction at 2026-07-20 16:09 Asia/Bangkok, logs show plugin/list, plugin/read, and app/list completing, followed by repeated renderer errors: ResizeObserver loop completed with undelivered notifications. The app/list request in this particular reproduction completed in 159 ms, so this instance looks like a renderer/UI-state failure rather than a request timeout.

Workaround: fully quit/restart Codex and avoid opening Plugins.

hewzhew · 18 days ago

Cross-reference from a current Windows Desktop reproduction of the post-tool continuation stall:

  • An inner command completed successfully and returned its tool result, but the outer tool card remained Running with no visible assistant continuation until manual interruption.
  • During one 90-second stalled sample, the primary renderer logged 71 occurrences of ResizeObserver loop completed with undelivered notifications.
  • In a same-operation successful comparison, continuation resumed in about 7 seconds and the corresponding interval contained 17 occurrences.
  • The app-server remained responsive during the stalled sample.

Detailed sanitized A/B evidence: https://github.com/openai/codex/issues/32714#issuecomment-5239059278

This is a correlated renderer signal, not proof that ResizeObserver is the root cause. It may nevertheless be useful when investigating renderer state desynchronization and disabled/stuck composer behavior across multiple task switches.