Copilot Desktop app freezes for minutes at a time during session resume; entire event loop blocks

# 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](https://github.com/user-attachments/files/30536868/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

1. **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.
2. **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.
3. **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).
4. **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.
5. 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..log` for multi-second gaps in *all* log activity (not just one session's messages) — the freeze is global, not per-session.

Beginne damit, session resume zu reproduzieren, während du ~/.copilot/logs/github-app/.log auf Lücken in allen Aktivitäten überwachst. Prüfe die erwähnten Rust-Backend-Pfade für git credential helpers, CLI subprocess teardown, CAFE metrics und artifact/session-resume fetches. Als abgeschlossen gilt die Aufgabe, wenn eine festgefahrene Operation nicht mehr die gesamte event loop blockiert und wiederholte resume failures den Tab nicht dauerhaft hängen lassen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.