"Connected Connectors could not be loaded" on every interactive session, but succeeds in headless -p mode; underlying error only logged at debug level #5347

Summary

Every interactive CLI session prints:

[WARNING] Connected Connectors could not be loaded; existing local and self-hosted MCP servers remain available.

The same CLI version, same account and same working directory load Connectors successfully in non-interactive (-p) mode. So this appears to be specific to the interactive session-startup path, not to the account's Connectors configuration.

Version

1.0.105 (linux-x64, Node v24.22.1). CONNECTORS feature flag resolves to true for this account, so Connectors are enabled and failing rather than disabled.

Observed behaviour

The warning appears on every interactive startup in all five of my retained session logs (2026-10-29, 2026-10-30 x2, 2026-11-02, 2026-11-03) — 100% reproduction rate, going back as far as log retention allows.

The emitting code is byte-identical between 1.0.103 and 1.0.105 (reportManagedConnectorFailure in cli-main.js), so this is not a recent regression — it just looks like a long-standing failure.

Not reproducible headlessly

I ran, with debug logging enabled:

copilot --log-level debug --log-dir <dir> --allow-all-tools -p "reply with OK only"

twice — once in an empty /tmp directory, once in the large git repo where the interactive sessions fail. Neither run produced the warning. Both emitted connector_client_operation telemetry and completed Connector loading cleanly.

Why that matters for diagnosis

Looking at beginManagedConnectorLoad in cli-main.js, interactive sessions appear to take a different branch from headless ones:

let r = t.authInfo === void 0
  ? { apply: s => n.currentAndApplyToSession(t.nativeSessionId, s),
      current: s => n.currentForSession(t.nativeSessionId, s) }
  : void 0;

When r is set, the code applies session credentials and races them against an AbortSignal.timeout(...), with failure paths that throw "The active GitHub account changed while loading Connectors". Headless -p runs supply authInfo and skip that path entirely. That session-credential/timeout branch looks like the likely culprit.

Main request: the failure cause is unobservable

The underlying exception is only logged on the failure path:

T.warning(r);
T.debug(`Copilot Connectors session integration failed: ${k(n)}`);

Since the failure reproduces only interactively, and --log-level debug is most naturally exercised via -p, there is effectively no way for a user to capture the real error. I could not obtain it despite the failure occurring 100% of the time interactively.

Concretely, it would help a lot if:

1. The underlying cause were logged at warning level alongside the user-facing message (or at least included in it), rather than only at debug.
2. The user-facing warning distinguished "timed out", "account changed", and "server error", since the remediation differs wildly.

Possibly related

I am simultaneously seeing GET /copilot_internal/managed_settings return 422 Validation Failed on this account (filed separately). Connectors sit on the same managed/enterprise settings surface, so these may share a root cause — though the Connectors failure clearly predates the 422 by at least a week.

Impact

Local and self-hosted MCP servers continue to work, so impact is limited to Connectors being unavailable plus a startup warning on every session.