Summary
Opening Customize triggers CloudTest OAuth recovery in a temporary MCP status session. The app then bumps the global MCP refresh generation and eagerly refreshes all 30 UI-attached sessions, even though neither MCP configuration nor user settings changed. This produces simultaneous MCP reloads, Windows process-tree termination timeouts, and several minutes of disruption.
Environment
- Windows
- GitHub Copilot desktop executable product/file version: 1.1.16
- Bundled Copilot CLI: 1.0.83-5
- Captured incident: September 8, 2026, 22:17 PDT / September 9, 2026, 05:17 UTC
- 30 UI-attached sessions; CloudTest MCP configured
Reproduction
- Have multiple sessions attached with MCP servers configured, including CloudTest.
- Open Customize. The captured visit opened Featured, then MCP servers.
- When the temporary MCP status session encounters the CloudTest OAuth callback, observe the global MCP refresh and process churn.
The reporter says opening Customize repeatedly causes this symptom. The sequence below was established from one existing incident's logs and a subsequent process snapshot; we did not deliberately trigger another storm or establish a minimal reproduction. The exact authentication precondition still needs isolation.
Expected
Viewing Customize or recovering one server's status should not force every attached session to reload its MCP graph. Status-session authentication recovery should be scoped to the affected server/session where possible.
Actual and evidence
Log timestamps below are UTC. Paths and request/session identifiers have been omitted.
From github-app.229928.log:
- Lines 24424-24425, 05:17:39.480-481:
subscribe_mcp_status with include_connectors=true; creating MCP status session, scope=Global.
- Line 24452, 05:17:45.951:
MCP status session created, scope=Global.
- Line 24454, 05:17:47.379:
MCP OAuth non-first-party server; cancelling host-token and kicking daemon-owned reconnect so the status badge can resolve, server_name=cloudtest.
- Line 24457, 05:17:55.527:
MCP refresh generation bumped mcp_config_changed=false user_settings_changed=false target_process_mcp_config=0 target_process_user_settings=0 target_session_mcp=1.
- Line 24458, immediately afterward:
eager extensibility live-session refresh spawning for UI-attached sessions attached_session_count=30.
- Lines 24589-24590, 05:19:21: the temporary MCP status session is force-destroyed/reaped, but the fan-out refresh work continues.
- The 30 subsequent
extensibility live-session refresh completed records have durations from 142,158 ms to 273,838 ms.
From process-1788910238432-168544.log:
- Starting at line 133652, 05:17:55.532: 23
mcp graph load: reload_forced records in that same second in a single pooled CLI process.
- Lines 133856-133892, starting 05:18:01.998: repeated
mcp::process_tree messages, taskkill tree termination timed out, error=Elapsed(()).
A subsequent process snapshot around 22:28 PDT showed 149 copilot.exe processes with 17.20 GiB summed working sets. One app-owned pooled CLI had 91 extension-bootstrap child processes and 23 computer-use MCP children. Many extension workers predated this Customize visit by hours, so those totals are background pressure, not a measured process delta attributable to this incident. Their retention may be a separate lifecycle issue.
Suspected fault boundary
High confidence in the observed chain: Customize subscription -> temporary status session -> CloudTest OAuth recovery -> global MCP generation bump -> eager refresh across 30 sessions -> concurrent reload/teardown and timeouts.
Please investigate github_app::session::manager::mcp_status and github_app::session::manager::cli_pool, particularly mcp_status_third_party_reconnect. A status-badge recovery appears to invalidate MCP state for unrelated live sessions. Also investigate Windows teardown behavior under that fan-out. This is log-based attribution, not a source-verified fix.
Suggested regression coverage
- Recover a third-party MCP server in a Customize status session with multiple unrelated live sessions attached; assert unrelated MCP graphs/processes are not restarted.
- Repeatedly open/close Customize during pending authentication; assert bounded startup/retry work and completed teardown.
- Exercise Windows child-process cleanup under concurrent MCP refresh without accumulating workers.
Summary
Opening Customize triggers CloudTest OAuth recovery in a temporary MCP status session. The app then bumps the global MCP refresh generation and eagerly refreshes all 30 UI-attached sessions, even though neither MCP configuration nor user settings changed. This produces simultaneous MCP reloads, Windows process-tree termination timeouts, and several minutes of disruption.
Environment
Reproduction
The reporter says opening Customize repeatedly causes this symptom. The sequence below was established from one existing incident's logs and a subsequent process snapshot; we did not deliberately trigger another storm or establish a minimal reproduction. The exact authentication precondition still needs isolation.
Expected
Viewing Customize or recovering one server's status should not force every attached session to reload its MCP graph. Status-session authentication recovery should be scoped to the affected server/session where possible.
Actual and evidence
Log timestamps below are UTC. Paths and request/session identifiers have been omitted.
From
github-app.229928.log:subscribe_mcp_statuswithinclude_connectors=true;creating MCP status session,scope=Global.MCP status session created,scope=Global.MCP OAuth non-first-party server; cancelling host-token and kicking daemon-owned reconnect so the status badge can resolve,server_name=cloudtest.MCP refresh generation bumped mcp_config_changed=false user_settings_changed=false target_process_mcp_config=0 target_process_user_settings=0 target_session_mcp=1.eager extensibility live-session refresh spawning for UI-attached sessions attached_session_count=30.extensibility live-session refresh completedrecords have durations from 142,158 ms to 273,838 ms.From
process-1788910238432-168544.log:mcp graph load: reload_forcedrecords in that same second in a single pooled CLI process.mcp::process_treemessages,taskkill tree termination timed out,error=Elapsed(()).A subsequent process snapshot around 22:28 PDT showed 149 copilot.exe processes with 17.20 GiB summed working sets. One app-owned pooled CLI had 91 extension-bootstrap child processes and 23 computer-use MCP children. Many extension workers predated this Customize visit by hours, so those totals are background pressure, not a measured process delta attributable to this incident. Their retention may be a separate lifecycle issue.
Suspected fault boundary
High confidence in the observed chain: Customize subscription -> temporary status session -> CloudTest OAuth recovery -> global MCP generation bump -> eager refresh across 30 sessions -> concurrent reload/teardown and timeouts.
Please investigate
github_app::session::manager::mcp_statusandgithub_app::session::manager::cli_pool, particularlymcp_status_third_party_reconnect. A status-badge recovery appears to invalidate MCP state for unrelated live sessions. Also investigate Windows teardown behavior under that fan-out. This is log-based attribution, not a source-verified fix.Suggested regression coverage