[macOS Desktop] Queued messages disappear after switching chats; Scheduled or Plugins restores them

What version of the Codex App are you using (From “About Codex” dialog)?

Desktop app 26.908.40834, build 8881. Verified from application metadata; the About dialog was not separately inspected.

What subscription do you have?

Not included in this report.

What platform is your computer?

macOS, Codex desktop app.

What issue are you seeing?

Queued follow-up messages repeatedly disappear from the chat UI after switching to another running chat and then returning. Visiting a non-chat page such as Scheduled or Plugins, then returning to the affected chat, makes the queued messages visible again.

I observe this in a chat where a substantial amount of work has already been done and there are many queued messages. I cannot tell whether a long history or a particular queue size is necessary; no threshold has been established.

The navigation sequence matters:

• Chat A → another running chat B → chat A: all queued messages in A disappear from view.
• Chat A → Scheduled or Plugins → chat A: the queued messages reappear.

This makes it difficult to inspect or manage pending instructions and to know what is still queued. No edit/resubmit action is needed in the sequence being reported here.

What steps can reproduce the bug?

User-reported sequence:

1. Have an active chat A with substantial existing history and several pending queued follow-up messages.
2. Confirm that its queued messages are visible.
3. Select a different chat B that is also currently working.
4. Select chat A again. Its queued messages are no longer visible.
5. Open Scheduled or Plugins from the app navigation, then select chat A again. The queued messages reappear.
6. Switch from A to the other running chat B and back again. The queued messages disappear again.

What is the expected behavior?

Returning to a chat should reliably display its current pending queue without requiring a detour through Scheduled or Plugins. Queue content and ordering should remain inspectable after both chat-to-chat navigation and navigation through a non-chat page.

Additional information

Evidence and limits: The navigation behavior and recurrence are the user's observations. The app version was independently checked, but this symptom has not been reproduced through UI automation or instrumented with a backend queue trace. The messages reappearing establishes a visible recovery in the reported workflow; it does not prove their storage state, eventual delivery, or execution order. This report does not claim permanent deletion or a confirmed root cause.

Suggested investigation: Compare queue loading/subscriptions and thread-specific view state when changing the selected chat within the conversation view versus leaving that view for Scheduled/Plugins and returning. The different recovery behavior suggests a state-refresh or view-lifecycle issue, but that remains a hypothesis. Test long and short histories, multiple queued items, and switching between two active chats.

Related reports checked:

• #44781 concerns editing/resubmitting a queued message and a missing-follow-up error. This report concerns queue visibility after navigation; it does not establish a shared cause.
• #43819 reports intermittent disappearance and unexpected Queue-to-Steer behavior on Windows. It does not identify this chat-switch trigger and Scheduled/Plugins recovery sequence.

No matching report with this specific navigation sequence was found. Please link or consolidate if maintainers identify the same underlying issue.

Start by reproducing the macOS desktop sequence with two running chats, then compare queue loading or subscriptions and thread-specific view state when switching chats versus returning from Scheduled or Plugins. Done means queued messages remain visible, ordered, and inspectable after both navigation paths.