Desktop app enters bad state where sessions stop executing and prompts appear twice

[zahidma-91]

Short summary

The Copilot desktop app enters a bad state where existing sessions remain marked as Running but stop executing, interrupted sessions cannot be resumed, new sessions make no progress, and every submitted prompt appears twice: once as sent and once as Pending. Copilot CLI continues to work normally at the same time.

Affected version or release

v1.1.15

Installation context

GitHub Copilot desktop app for Windows

What happened?

The desktop app entered an app-wide bad state affecting multiple sessions and message delivery:

• An existing running session stopped executing but continued to show Running, even though no work was happening.
• The session eventually displayed: Session appears to have been interrupted. The session stopped responding before the response finished.
• Clicking Resume did not recover it, and subsequent messages received no response.
• Creating a new session did not help. The new session accepted a prompt but stopped with no progress or response.
• Every prompt submitted while the app was in this state appeared twice in the conversation: one normal sent message and a second duplicate marked Pending.
• The pending duplicate remained visible and was not processed.
• A new session displayed an MCP sign-in notice for s360-breeze, but did not continue or otherwise report that the session had failed.
• Copilot CLI continued to work as expected during the same period, suggesting the problem was isolated to the desktop app rather than the account, service, or local Copilot environment generally.

Once this state occurs, the desktop app appears unable to execute work in either existing or new sessions, and its message state becomes inconsistent.

Steps to reproduce

The issue is intermittent, but the observed sequence was:

1. Run work in an existing Copilot desktop app session.
2. Observe that the session remains marked as Running but stops executing and produces no further activity.
3. Wait until the app reports that the session appears to have been interrupted.
4. Click Resume and send follow-up messages.
5. Observe that the existing session remains stuck and does not respond.
6. Create a new session and submit a simple prompt such as Hello or hey.
7. Observe that the new session also stops with no progress or response.
8. Observe that the submitted prompt appears twice: once as sent and once as a duplicate marked Pending.
9. Run Copilot CLI separately and observe that it continues to work normally.

Expected behavior

• A running session should continue executing or transition to a clear failed/interrupted state instead of remaining falsely marked as Running.
• Resume should recover an interrupted session or clearly explain why recovery failed.
• A failure in one session should not prevent newly created sessions from executing.
• Each submitted prompt should appear exactly once and should not leave a duplicate pending message.
• An MCP server requiring sign-in should not block the entire session; the app should continue without that server or clearly expose a recoverable action.

Additional context

• Platform: Windows
• App version: v1.1.15
• Affected existing session showed: Claude Opus 5, Extra High, Plan mode
• A newly created session also failed to make progress.
• All prompts displayed both a sent copy and a duplicate Pending copy while the app was in this state.
• Copilot CLI worked normally while the desktop app was in the bad state.
• Screenshots of the interrupted session, stalled new session, and duplicate sent/pending message will be attached manually.

Issue #1:

Issue #2:

Issue #3:

[raykao]

Seeing similar session connectivity and recovery problems on macOS with app v1.1.15, not only Windows.

Environment

Component	Version / configuration
OS	macOS 26.6.2, build 25G83
Architecture	arm64 (Apple Silicon)
GitHub Copilot app	1.1.15
Running bundled CLI	1.0.83-5
Affected session model	GPT-6 Astra (gpt-6-astra), medium reasoning
Earlier model in that session	GPT-5.6 Terra (gpt-5.6-terra), medium reasoning
Mode	Autopilot
Workspace	Local, in-place Git checkout, not an app-managed worktree

Observed behavior

An existing session was running implementation work in Autopilot. After I started another session for unrelated work in the same project, the original session disappeared from the UI and I could no longer reconnect to it. It initially looked as though it had been deleted.

Read-only diagnostics found that:

• The original CLI process was still alive.
• Its saved transcript continued recording tool execution after the new session started, including activity at 2026-09-05 02:09 UTC.
• The original session was absent from the app’s session-list tool results.
• Looking up the original session ID through the app’s session-details tool returned the newer session’s identity instead.
• The original transcript and implementation workspace remained on disk.

The replacement/new sessions were also using GPT-6 Astra with medium reasoning.

Important distinction

This overlaps with the inaccessible/unresponsive session symptoms here, but the hidden session was still executing work, rather than merely showing a stale Running indicator. I have not confirmed the duplicate sent/Pending prompt symptom from the original report.

This suggests a UI/session-association or reconnect problem, but the underlying cause is not yet established. An apparently lost session may still be modifying files in the background.

No app restart, process termination, or session-state modification was performed during these diagnostics.