Desktop app freezes for minutes at a time during session resume; entire event loop blocks
Environment
- GitHub Copilot Desktop v1.1.2 (Windows)
- OS: Windows 11
- Security stack: CrowdStrike Falcon Sensor (active), Palo Alto GlobalProtect VPN
GITHUB_APP_DATADOG_METRICS=off set (confirmed via log: Datadog metrics disabled (kill switch or local/dev build))
Attempted copilot--assisted analyses of session logs. Originally on older and today latest version of Desktop. May also be seeing similar behaviour in CLI but not as severe, and didn't seem to be there originally.
I've included the session log extract for the latest attempt.
Latest attempt
- GitHub Copilot Desktop v1.1.2 (Windows)
Key finding: the resume-stall bug persists post-update but with a much cleaner signature than before — resume_session hits an exact 60-second hard timeout ("session resume timed out ... the CLI process may be unresponsive") three times in a row (07:16:26, 07:17:31, 07:18:36), each followed by an automatic retry that spawns a new CLI process, then after the 3rd failure Desktop silently stops retrying with no further resume attempts — leaving the tab permanently stuck. Also noted a secondary, likely separate bug: repeated git-fetch failures for a stale/deleted base branch ref, recurring every 1-3 minutes.
resume-stall-log-excerpt-minimal.txt
Previous attempts
- GitHub Copilot Desktop v1.0.22 (Windows)
Summary
Desktop intermittently freezes completely — not just a specific session, the entire app's event loop stops processing, including trivial UI events (set_app_activity) and unrelated WebSocket traffic for other sessions/workspaces. The UI shows "failed, retry" on session resume, which sometimes silently succeeds once the freeze clears. Freeze durations observed: mostly sub-second, with recurring outliers of 8–20s, and one confirmed 4 minute 29 second total freeze (07:40:01 → 07:44:30 UTC on 2026-07-14) while resuming session 05fe0253-eb8a-427b-9c97-0d9e6a235a63 (last log line before the freeze: an artifact_list request for that session).
Evidence gathered / causes ruled out
- Not a zombie/orphaned process — an earlier suspect (a runaway CLI subprocess left behind by an in-session auto-update, ~270% CPU) was found and fixed via full app restart; freezes continued afterward, ruling this out as the ongoing cause.
- Not Datadog/CAFE telemetry — Desktop sends periodic metrics via an internal proxy (
cafe.github.com, /twirp/clientappsfe.observability.v1.TelemetryAPI/SubmitMetrics). This call was found to occasionally take 17–19.5s, always immediately followed by a full log silence gap — a plausible cause. However, after setting the built-in kill switch (GITHUB_APP_DATADOG_METRICS=off, confirmed active via log line Datadog metrics disabled (kill switch or local/dev build), zero CAFE sends afterward), the same freeze pattern continued, ruling this out as sole cause.
- Not GlobalProtect VPN — confirmed VPN adapter fully disabled (
PANGP Virtual Ethernet Adapter Secure: Disabled) during a run that still showed multiple 8–20s freezes, ruling out VPN/TLS-inspection interference as sole cause (unlike a separate, apparently VPN-specific issue reported for Claude Desktop/CLI on the same network).
- Not CPU-bound / not antivirus-scan overhead — during the observed freezes (including the 4m29s one), CPU usage across
github.exe, git.exe, and CrowdStrike (CSFalconService/CSFalconContainer) processes was consistently ~0% for the entire duration — consistent with a thread blocked in a synchronous wait (e.g., an un-timed-out network/IPC call), not a busy loop or scan overhead.
- Attempted to capture a process memory dump of the frozen
github.exe during the live 4m29s freeze using a standard OS-native diagnostic dump utility; the attempt was blocked by EDR policy (expected security behavior — dump utilities of this kind are commonly restricted by endpoint security tooling, not itself a bug).
Suspected root cause
Different operations have each been observed immediately preceding a freeze at different times (Datadog/CAFE metrics send, git credential-store trampoline calls, CLI subprocess teardown, artifact_list fetch). This pattern — many different operations, each individually rare, each followed by total silence across the whole app, not just the current session — suggests these operations may share a single blocking executor/thread, so any one of them stalling (e.g., an unbounded/un-timed-out network call to a backend service) freezes the entire app rather than just the operation in question.
Suggested fix direction: audit blocking/synchronous calls in the Rust backend (git credential helper invocation, CLI subprocess lifecycle, CAFE metrics client, artifact/session-resume fetches) to ensure none run directly on a shared async executor thread without spawn_blocking or an enforced timeout.
Repro tips for maintainers: resume a session with a non-trivial workspace/worktree history repeatedly over a working session; watch ~/.copilot/logs/github-app.<pid>.log for multi-second gaps in all log activity (not just one session's messages) — the freeze is global, not per-session.
Desktop app freezes for minutes at a time during session resume; entire event loop blocks
Environment
GITHUB_APP_DATADOG_METRICS=offset (confirmed via log:Datadog metrics disabled (kill switch or local/dev build))Attempted copilot--assisted analyses of session logs. Originally on older and today latest version of Desktop. May also be seeing similar behaviour in CLI but not as severe, and didn't seem to be there originally.
I've included the session log extract for the latest attempt.
Latest attempt
Key finding: the resume-stall bug persists post-update but with a much cleaner signature than before — resume_session hits an exact 60-second hard timeout ("session resume timed out ... the CLI process may be unresponsive") three times in a row (07:16:26, 07:17:31, 07:18:36), each followed by an automatic retry that spawns a new CLI process, then after the 3rd failure Desktop silently stops retrying with no further resume attempts — leaving the tab permanently stuck. Also noted a secondary, likely separate bug: repeated git-fetch failures for a stale/deleted base branch ref, recurring every 1-3 minutes.
resume-stall-log-excerpt-minimal.txt
Previous attempts
Summary
Desktop intermittently freezes completely — not just a specific session, the entire app's event loop stops processing, including trivial UI events (
set_app_activity) and unrelated WebSocket traffic for other sessions/workspaces. The UI shows "failed, retry" on session resume, which sometimes silently succeeds once the freeze clears. Freeze durations observed: mostly sub-second, with recurring outliers of 8–20s, and one confirmed 4 minute 29 second total freeze (07:40:01 → 07:44:30 UTC on 2026-07-14) while resuming session05fe0253-eb8a-427b-9c97-0d9e6a235a63(last log line before the freeze: anartifact_listrequest for that session).Evidence gathered / causes ruled out
cafe.github.com,/twirp/clientappsfe.observability.v1.TelemetryAPI/SubmitMetrics). This call was found to occasionally take 17–19.5s, always immediately followed by a full log silence gap — a plausible cause. However, after setting the built-in kill switch (GITHUB_APP_DATADOG_METRICS=off, confirmed active via log lineDatadog metrics disabled (kill switch or local/dev build), zero CAFE sends afterward), the same freeze pattern continued, ruling this out as sole cause.PANGP Virtual Ethernet Adapter Secure: Disabled) during a run that still showed multiple 8–20s freezes, ruling out VPN/TLS-inspection interference as sole cause (unlike a separate, apparently VPN-specific issue reported for Claude Desktop/CLI on the same network).github.exe,git.exe, and CrowdStrike (CSFalconService/CSFalconContainer) processes was consistently ~0% for the entire duration — consistent with a thread blocked in a synchronous wait (e.g., an un-timed-out network/IPC call), not a busy loop or scan overhead.github.exeduring the live 4m29s freeze using a standard OS-native diagnostic dump utility; the attempt was blocked by EDR policy (expected security behavior — dump utilities of this kind are commonly restricted by endpoint security tooling, not itself a bug).Suspected root cause
Different operations have each been observed immediately preceding a freeze at different times (Datadog/CAFE metrics send, git credential-store trampoline calls, CLI subprocess teardown,
artifact_listfetch). This pattern — many different operations, each individually rare, each followed by total silence across the whole app, not just the current session — suggests these operations may share a single blocking executor/thread, so any one of them stalling (e.g., an unbounded/un-timed-out network call to a backend service) freezes the entire app rather than just the operation in question.Suggested fix direction: audit blocking/synchronous calls in the Rust backend (git credential helper invocation, CLI subprocess lifecycle, CAFE metrics client, artifact/session-resume fetches) to ensure none run directly on a shared async executor thread without
spawn_blockingor an enforced timeout.Repro tips for maintainers: resume a session with a non-trivial workspace/worktree history repeatedly over a working session; watch
~/.copilot/logs/github-app.<pid>.logfor multi-second gaps in all log activity (not just one session's messages) — the freeze is global, not per-session.