[Bug] 1.1.3 session repair health checks fail during concurrent CLI startup timeouts

[JonathonClaypool]

Short summary

After the in-app update to 1.1.3 on Windows, existing sessions were shown as needing repair and their health checks intermittently succeeded and failed. The app repeatedly times out starting bundled Copilot CLI processes used for skills, MCP configuration, and project canvas-catalog probes.

Affected version or release

GitHub Copilot app 1.1.3 on Windows 11 ARM64
Bundled Copilot CLI: 1.0.78-2

Installation context

The app was updated in place to 1.1.3. The local database contains 57 sessions across 12 projects. Several projects are local Windows paths and several are WSL UNC paths.

What happened?

Immediately after updating, the app reported that previous sessions could not be connected until repaired. Repair/health checks alternated between success and failure.

The database migration itself succeeded (from_version=60 to_version=75), and PRAGMA quick_check reports ok for both data.db and session-store.db. Authentication checks also pass.

During startup the app launches many bundled copilot.exe --server --stdio --no-auto-update child processes concurrently. Some start, while others hit the fixed 30-second timeout. Representative sanitized log messages:

ERROR github_app::handlers::skills_config: failed to list global skills error=operation timed out: starting the skills config client exceeded 30s
WARN github_app::session::manager::cli_pool: cold CLI spawn/handshake timed out; killing the partial process and failing the acquisition timeout_s=30
WARN github_app::session::manager::canvas_catalog: project canvas catalog probe failed error=operation timed out: CLI process startup did not complete within 30s
ERROR github_app::handlers::mcp_config: failed to list MCP config servers error=operation timed out: starting the MCP config client exceeded 30s

A complete silent uninstall followed by a fresh installation of 1.1.3 from the official WinGet package did not resolve the timeouts. The session databases remained intact and all 57 session records are still present.

Steps to reproduce

1. Have an existing installation with multiple local/WSL projects and prior sessions.
2. Update in-app to version 1.1.3.
3. Relaunch the app.
4. Observe previous sessions marked as requiring repair and intermittent health-check results.
5. Inspect the app log while startup probes run.

Expected behavior

Existing sessions should reconnect after a successful database migration. Startup health/catalog probes should not fail because multiple bundled CLI processes cannot finish their handshake within 30 seconds.

Additional context

The closed migration issue #14 recommends uninstalling and reinstalling the latest version. That remediation was attempted here but the CLI startup/handshake timeouts persisted. A pre-update database backup was created automatically, and an additional manual backup was made before reinstalling.

[JonathonClaypool]

Additional diagnostic finding from the affected ARM64 Windows 11 machine:

• Ubuntu WSL startup also failed with Wsl/Service/CreateInstance/Plugin/E_UNEXPECTED naming DefenderforEndpointPlug-in.
• Microsoft documents that the Defender for Endpoint WSL plug-in is not supported on ARM64 processors: https://learn.microsoft.com/en-us/defender-endpoint/mde-plugin-wsl#known-issues-and-limitations
• Plug-in healthcheck reported version 1.26.128.1, WSL 2.6.1, Defender 101.25102.0005, and successful connectivity despite the startup failure.
• wsl --shutdown followed by restarting Ubuntu restored WSL startup.
• Rolling the Copilot app back to 1.1.2 with its automatic pre-1.1.3 database snapshot restored responsive startup and preserved all 57 sessions.

The 1.1.3 app's concurrent probes of WSL-backed projects appear able to repeatedly encounter or amplify this WSL plug-in failure. This may be especially relevant to ARM64 users with the MDE WSL plug-in deployed by policy.