fix: degrade Copilot CLI session listing when SDK native addon is unavailable on musl Linux (fixes #321635)

[vs-code-engineering]

Summary

The Copilot CLI chat-sessions provider throws an unhandled Error: Native addon "runtime" not found for linuxmusl-x64 ... on every session-list refresh for users on musl-libc Linux (e.g. Alpine). The third-party @github/copilot SDK's LocalSessionManager constructor eagerly builds an experimentation / feature-flag service that loads a native runtime.node addon, and the SDK ships no linuxmusl-x64 prebuild. Because the session manager is a cached Lazy, the rejected promise is reused, so each provideChatSessionItems refresh re-awaits it and re-throws.

Telemetry for this bucket: 11,193 hits / 2,747 users, present from 1.124.0 through 1.125.0 (≈4 hits/user, consistent with repeated refreshes per session).

This change marks the session manager permanently unavailable the first time initialization fails (still logged via logService.error) and short-circuits the automatic refresh path to an empty list thereafter, so the feature degrades to "no CLI sessions" on unsupported platforms instead of repeatedly reporting an unhandled error. The first failure and all user-initiated paths still log and throw unchanged.

Fixes #321635
Recommended reviewer: @joshspicer

Culprit Commit

Not precisely identifiable from the shallow CI clone (grafted to a single commit; no git history available for git blame). Telemetry first recorded this bucket in 1.124.0-insider builds on 2026-06-03 (e.g. commit f5d16d03...) and it is present through 1.125.0, indicating the trigger landed during the 1.124 milestone — most plausibly when the Copilot CLI chat-sessions provider began enumerating sessions on startup, which constructs the SDK LocalSessionManager and eagerly loads the experimentation native addon. The throw itself originates in third-party SDK code (@github/copilot/sdk), which cannot be patched from this repository.

Code Flow

flowchart TD
    A["MainThread → $refreshChatSessionItems"] --> B["ExtHostChatSessions.refreshHandler<br/>(no try/catch)"]
    B --> C["CopilotCLIChatSessionsContribution.provideChatSessionItems"]
    C --> D["CopilotCLISessionService.getAllSessions"]
    D --> E["_getAllSessions → getSessionManager()"]
    E --> F["_sessionManager Lazy:<br/>new internal.LocalSessionManager(...)"]
    F --> G["SDK createFeatureFlagService<br/>loads native runtime.node addon"]
    G --> H["throw: Native addon 'runtime'<br/>not found for linuxmusl-x64"]
    H -. "cached rejected promise reused<br/>on every refresh" .-> E
    H ==> I["Unhandled error → telemetry<br/>(escapes at refreshHandler)"]

Loading

Affected Files

• extensions/copilot/src/extension/chatSessions/copilotcli/node/copilotcliSessionService.ts — modified. Adds an availability flag set when the session manager fails to initialize, plus a guard clause in the automatic getAllSessions refresh path.

Repro Steps

1. Run VS Code on a musl-libc Linux distribution (e.g. Alpine) on x64, where @github/copilot ships no linuxmusl-x64 native runtime prebuild.
2. Ensure the Copilot Chat extension is active and the Copilot CLI chat-sessions provider is registered.
3. Open or refresh the chat-sessions view (or trigger any session-list refresh, e.g. via the session-file watcher).
4. Observe the unhandled error Native addon "runtime" not found for linuxmusl-x64 ... reported on each refresh.

How the Fix Works

Chosen approach — extensions/copilot/src/extension/chatSessions/copilotcli/node/copilotcliSessionService.ts:

• The producer of the failure is the _sessionManager Lazy, which constructs new internal.LocalSessionManager(...). On musl this throws, and because Lazy caches the rejected promise the manager is permanently unavailable for the window's lifetime. A new _sessionManagerUnavailable field is set inside that Lazy's existing catch — the same place that already calls logService.error(...) and re-throws — so the first failure and every user-initiated path (resolve / create a session) still log and throw exactly as before.
• The only path that runs automatically and repeatedly is provideChatSessionItems → getAllSessions. A guard clause at the top of getAllSessions returns an empty list once the manager is known-unavailable, so the automatic refresh degrades gracefully to "no CLI sessions" instead of re-awaiting the cached rejected promise and re-throwing.
• This follows the upstream-guard / fix-at-the-data-producer principle: the change sits in the service that owns the failing producer — not at the SDK crash site, and not at the shared extHostChatSessions boundary that every chat-session provider funnels through. It adds a guard clause rather than a symptom-silencing try/catch, and it preserves the existing logService.error so telemetry still records the condition once per session.

After this change, once the SDK session manager fails to initialize (logged at the Lazy catch), getAllSessions returns [] on every subsequent refresh, so provideChatSessionItems / refreshHandler can no longer re-await the cached rejected promise and re-throw — eliminating the repeated unhandled error — while the first failure and all user-initiated paths continue to log and throw for telemetry.

Alternatives considered:

• Wrap provideChatSessionItems / refreshHandler in try/catch: rejected — it sits at the shared core boundary used by every chat-session provider and would swallow genuine bugs from all of them, hiding the cause instead of guarding the specific unsupported-platform producer.
• Proactively detect musl and skip registering the provider: rejected — reliable musl detection from Node is fragile (no stable API; would require process.report glibc probing or /etc/alpine-release sniffing) and duplicates platform knowledge the SDK's own addon loader already encodes; the SDK load is the authoritative availability signal.
• Make the _sessionManager Lazy retry on failure: rejected — the failure is permanent on unsupported platforms, so a retry would simply re-throw and would not address the repeated reporting.

Recommended Owner

@joshspicer — owns "Chat Sessions → Extension API" in the VS Code team working-areas. The unhandled error escapes through the Chat Sessions extension API (extHostChatSessions.ts refreshHandler / $refreshChatSessionItems), and the fix lives in the Copilot CLI session provider that integrates with that API. (@osortega owns the "Chat Sessions View" UI, which is not where this enumeration failure occurs.)

Generated by errors-fix · 1.8K AIC · ⌖ 130.2 AIC · ⊞ 69.2K · ◷

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.