[1.1.18][Windows] Main window becomes Not Responding while backend and agent work continue

Short summary

On Windows, GitHub Copilot app 1.1.18 became Not Responding approximately 12 minutes after a successful launch. Its existing native main window stops answering messages, but the desktop backend and an active agent session continue doing work.

This is a post-startup UI hang, not the windowless-startup failure reported in #3681, and not merely a session that stops generating a response.

Affected version or release

• GitHub Copilot app 1.1.18, commit b43d611, Windows x86_64.
• Similar prolonged native-window hangs were also observed on 1.1.17, but the current incident is independently confirmed on 1.1.18.

Installation context

• Windows 11 Enterprise 25H2, build 26200.9457, x64.
• Existing desktop profile with multiple projects and local sessions.
• The app automatically applied an already-deferred 1.1.18 update during recovery from the separate 1.1.17 startup problem.
• No profile reset, history deletion, database replacement, or browser-profile cleanup was performed.

What happened?

On September 15, 2026, local time UTC+02:00:

1. The 1.1.18 process started at 17:12:09. Its main window opened and was independently confirmed responsive.
2. Existing local sessions were resumed. The app log also records browser-preview activity during this run.
3. At 17:23:58, the user reported that the app was not responding again.
4. At 17:24:32 and on subsequent checks through 17:26, the same process and main-window handle remained present, but Windows reported the app as hung.
5. During the hang, an active session continued appending events and completing tools. The app backend also continued logging idle CLI cleanup.

The exact user action that triggered the transition is not known, and this has not been reproduced on demand in a clean profile.

Direct evidence

Native window state:

App version:           1.1.18
PID:                   3656
Process start:         2026-09-15 17:12:09 +02:00
MainWindowTitle:       GitHub Copilot
MainWindowHandle:      329428 (nonzero; unchanged from successful startup)
Responding:            False
IsHungAppWindow:       True
UI thread ID:          22384
UI thread state:       Wait
Reported wait reason:  Unknown

A bounded, non-mutating SendMessageTimeout(WM_NULL, SMTO_ABORTIFHUNG, 1000ms) probe returned zero/no response. No native stack was captured, so the blocking operation and any deadlock mechanism remain unknown.

Backend and worker activity during a 10-second sample at approximately 17:24:

Process	CPU time added	Read-transfer bytes added	Write-transfer bytes added
github.exe	0.25 s	481,124	18,606
Active app-owned copilot.exe worker	0.94 s	0	469,459

The desktop process had approximately 329 MiB working set. Available system memory was approximately 74.39 GiB out of 95.93 GiB; physical-memory exhaustion was not apparent.

There were 10 direct Copilot workers at the start of the sample and 7 on a later check. The app's own logs recorded idle-worker reaping during that interval. The active worker remained alive; no diagnostic action terminated any worker. Eight direct WebView2 child processes were also present on the later check.

Active work continues despite the hung native window:

• The app database remained readable and marked one session running.
• That session's event history grew from 101,717,407 bytes to 101,879,678 bytes during the observation interval.
• With the window still reporting Responding=False, newly persisted events included the following (timestamps are UTC):

2026-09-15T15:26:03.034Z  tool.execution_complete  success=true
2026-09-15T15:26:03.039Z  assistant.turn_end
2026-09-15T15:26:03.040Z  assistant.turn_start

This is direct activity evidence, not an inference based only on a stale Running label or a live process.

Relevant log context

The following earlier warnings occurred during the same app run. They may help correlate the incident, but are not established as the trigger or root cause. Identifiers and private paths are redacted; timestamps are UTC.

2026-09-15T15:18:07.467055Z WARN github_app::browser_preview:
Timed out waiting for browser preview initial navigation; continuing with requested URL label=<redacted>

2026-09-15T15:18:07.751871Z WARN github_app::browser_preview:
Failed to remove browser preview ephemeral profile directory
label=<redacted> path=<temporary-preview-profile>
error=The process cannot access the file because it is being used by another process. (os error 32)

2026-09-15T15:18:34.247099Z WARN github_app::browser_preview:
Timed out waiting for browser preview initial navigation; continuing with requested URL label=<redacted>

The desktop log continued recording idle_cli_reap_check / reaping idle pooled CLI process messages at approximately 15:24:35-15:24:38 UTC, while Windows reported the main window unresponsive. Therefore this observation does not show a total halt of all backend logging/execution.

Steps to reproduce

Observed sequence, not a deterministic minimal repro:

1. Launch 1.1.18 on Windows with an existing multi-session profile.
2. Confirm that the main application window is initially visible and responsive.
3. Resume local session work and use the app normally. Browser-preview activity was present in this run, but whether it is necessary to reproduce is unknown.
4. Within approximately 12 minutes of startup in this incident, observe the existing native window enter Not Responding.
5. Independently inspect native-window responsiveness, app/worker process activity, and session event timestamps.
6. Observe a hung main window alongside continuing backend and agent work.

Expected behavior

The main window should remain responsive while session work and browser previews run. If the window or UI thread stalls, the app should offer a recovery path that preserves session workers and pending work instead of requiring a full process termination.

An alive backend or a successful session-liveness probe should not be treated as proof that the user-facing native window is healthy.

Work-preservation impact and current status

The user cannot reliably steer or answer prompts through the frozen window even though an agent is still working. Force-terminating the app risks interrupting that work or losing memory-only UI input.

No app restart, process termination, session interruption, or profile modification was performed while investigating this recurrence. The window was still hung at the last check.

Related reports

• #3681, specifically https://github.com/github/app/issues/3681#issuecomment-5682941195: earlier windowless-startup failure and successful recovery/update on this machine. That recovery did not prevent this subsequent 1.1.18 UI hang.
• #2441: related Windows app freezes during session resume. Important distinction here: native-window unresponsiveness is confirmed, but backend logging and agent execution demonstrably continue. I cannot establish a shared root cause.

Only sanitized diagnostic excerpts and event metadata are included. Full logs, database backups, session histories, private paths, and conversation contents remain local.

No source files or tests are named. Start with the native-window and UI-thread evidence, then try to reproduce the Windows hang while collecting a native stack and correlating browser-preview and WebView2 activity. Done means identifying the blocking cause and defining a recovery path that preserves active session work.