Messages stay queued for about an hour in the app; CLI does not do this

Short summary

Messages stay queued in the Copilot app for a very long time (around an hour). The same workflow in Copilot CLI does not queue like this.

Affected version or release

1.1.17 (github.exe ProductVersion 1.1.17)

Installation context

Windows 11 Enterprise (build 26200), GitHub Copilot desktop app, conversation / chat view. Same work in Copilot CLI does not show this delay.

What happened?

In the GitHub Copilot app, a follow-up message can sit in the queue for a very long time (on the order of ~1 hour) before it is sent or processed.

This does not happen in Copilot CLI for the same kind of session. In CLI, the next message is picked up promptly. In the app, the message remains queued far longer than a normal turn, so the conversation looks stalled even though the user already submitted the next prompt.

Steps to reproduce

1. Open a conversation in the GitHub Copilot desktop app.
2. Send a message while the session is still working, or send a follow-up that the app places in the queue.
3. Wait. The queued message remains unsent / unprocessed for a very long time (around an hour in the observed case).
4. Repeat a similar follow-up in Copilot CLI. The next message is handled promptly and does not sit in a long queue.

Expected behavior

Queued messages in the app should start within a normal turn boundary, similar to Copilot CLI. They should not sit unprocessed for ~1 hour.

Additional context

Related, but not the same:

• https://github.com/github/app/issues/3525 (queued messages stuck because the session stays in Running and Send now fails)

This report is about long queue delay in the app (~1 hour), not a permanent stuck state, and the contrast with CLI where the delay does not occur.

Start by reproducing the queued follow-up behavior in the GitHub Copilot desktop app on Windows 11 with version 1.1.17, then compare the same workflow in Copilot CLI. Trace the app's queue processing around a still-running conversation and verify that queued messages begin within a normal turn boundary rather than waiting about an hour.