Queued follow-up message fails with “App-server queued follow-up no longer exists” #45209

Activity

1. ZmeyXAI

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 13, 2026
3. github-actions commented on Sep 13, 2026

   

   github-actionsBot

   on Sep 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • app server queued follow up no longer exists - error submitting message #45040
   • App-server queued follow-up no longer exists #45019
   • [Codex Desktop] Editing and resending a queued message triggers "App-server queued follow-up no longer exists" #44781

   Powered by Codex Action
4. vovapyc commented on Sep 14, 2026

   

   vovapyc

   on Sep 14, 2026

   More actions

   Up, I have the same problem
5. htbk commented on Sep 14, 2026

   

   htbk

   on Sep 14, 2026

   More actions

   Additional owner-authorized macOS occurrence on the same desktop version, with local log evidence. The owner reports that this recurs and appears to clear by itself.

   Environment inspected September 14, 2026

   • Desktop bundle com.openai.codex: 26.908.40834, build 8881.
   • Bundled executable: codex-cli 0.154.0-alpha.6.2.
   • macOS 26.6.2, arm64.

   Error and evidence

   Error submitting message
   App-server queued follow-up no longer exists
   

   Read-only inspection of desktop logs from September 11–14 found eight matching log entries, all on September 14. These are log occurrences, not necessarily eight distinct queued messages:

   2026-09-14T22:25:37.326Z
   2026-09-14T22:25:41.471Z
   2026-09-14T22:25:49.709Z
   2026-09-14T22:25:58.005Z
   2026-09-14T23:06:44.420Z
   2026-09-14T23:06:48.043Z
   2026-09-14T23:07:51.957Z
   2026-09-14T23:08:28.883Z
   

   One representative entry, reduced to relevant non-private fields:

   error [electron-message-handler] [Composer] submit failed
   errorMessage="App-server queued follow-up no longer exists"
   errorName=Error followUp=local mode=local
   

   The owner reports repeated message-submission failures followed by apparent spontaneous recovery. I have not independently established whether every affected instruction was eventually delivered, nor produced a deterministic isolated repro. In particular, I cannot confirm that this user's instances involved editing a queued message, even though related reports describe that trigger.

   Expected behavior and diagnostic request

   Queued follow-ups should remain durably associated with the task until they are acknowledged, cancelled or explicitly failed. If the queue identifier becomes stale during turn completion, steering, compaction or renderer reconciliation, the composer should reconcile the authoritative state and offer a safe retry without losing or duplicating the instruction.

   Please investigate the queue-item lifetime and the desktop/app-server acknowledgement path. The error and apparent recovery are consistent with a state/lifecycle race, but they do not by themselves prove an exclusively remote-backend cause. A disappearing error also does not establish successful delivery.

   No private message text, project paths, task IDs, complete logs or credentials are included. Related reports already identified: #45019, #45040 and #44781.
6. DanMailman commented on Sep 16, 2026

   

   DanMailman

   on Sep 16, 2026 – with ChatGPT Codex Connector

   More actions

   Additional affected user on Codex Desktop for Windows with a ChatGPT Pro subscription, observed September 16, 2026.

   Observed behavior

   1. Start or continue a Codex task and leave the current turn running.
   2. While that turn is still running, enter and submit a new follow-up prompt.
   3. The desktop app displays:

   Error submitting message
   App-server queued follow-up no longer exists
   

   4. The new prompt does not reach the chat and must be entered again.
   5. After the currently running turn finishes, prompt submission in that chat works again.

   This occurrence does not require editing or cancelling an existing queued prompt; it happens when simply attempting to add a new prompt while the current one is still running. That may help distinguish it from the edit/resubmit reports.

   Expected behavior: the prompt should remain queued and be delivered after the active turn, or the composer should preserve the unsent text and recover its queue state without discarding the prompt.

   A screenshot supplied by the affected user shows the exact error above. Exact Codex Desktop build was not captured.
7. unkarjedy commented on Sep 16, 2026

   

   unkarjedy

   on Sep 16, 2026

   More actions

   Having the same issue.
   Use this feature daily and sad that it's broken
8. NathanR-85 commented on Sep 17, 2026

   

   NathanR-85

   on Sep 17, 2026

   More actions

   I’m hitting this too on Codex App version 26.908.70816. The apparent workaround is to switch to another task and then return. After doing that, the edited queued message can be submitted again—but every other queued message in that task disappears. This appears related to #45019 and turns the recovery step into user-authored data loss.
9. elfege commented on Sep 20, 2026

   

   elfege

   on Sep 20, 2026

   More actions

   Additional occurrence on 2026-09-20 during an active, long-running Codex agent turn. I typed a new steering follow-up while the turn was still running. The composer showed:

   Error submitting message
   App-server queued follow-up no longer exists
   

   The follow-up remained in the composer but could not be submitted while the turn was active. I had to stop/interrupt the running turn to send it and continue the conversation. This was a live-workflow interruption, not a cosmetic toast: the user lost the ability to steer work in progress and had to force a state transition to regain the composer. I did not observe a successful queue acknowledgement for the failed attempt.

   This occurrence matches the active-turn path reported here more closely than the edit/resubmit path in #44781. The screenshot contains unrelated private project text, so I am reporting only the exact error and user-visible sequence. Please make queue-state reconciliation safe: a stale follow-up ID should recover or preserve the unsent message without requiring the user to interrupt a running agent, and the UI should state whether the follow-up was delivered, still queued, or needs retry.