1.0.88: workspace MCP servers blocked at startup because managed policy is resolved before GitHub auth

The bug is in the managed-settings policy resolution during session startup, likely in the authentication orchestration or policy fetch timing. Start by examining the logs to trace the sequence: 'no authenticated GitHub host available' leads to a fail-closed policy. Look at the code handling managed settings and MCP server loading, focusing on the order of authentication and policy application. Check for recent changes around version 1.0.88 related to enterprise managed settings. Running a local session with debug logging can help reproduce the timing issue.

Describe the bug

Since upgrading to Copilot CLI 1.0.88, new sessions started by the GitHub Copilot desktop app intermittently skip every workspace and plugin MCP server with blocked by enterprise customization lockdown. The logs show the managed-settings server policy fetch is skipped because no authenticated GitHub host is available yet. The GitHub token resolves as authenticated about 3 seconds later, but by then the session has already applied the fail-closed policy and skipped the MCP servers. The session stays in that state for its lifetime.

Impact

Affected sessions silently lose every repository MCP server (work tracking, telemetry, design, and documentation tools) with no user-visible warning. Restarting the session is the only workaround, and it does not always help.

Environment

• GitHub Copilot app v1.1.23 (Windows)
• Copilot CLI 1.0.88 (copilot --version); sessions on 1.0.87-0 were not affected
• GitHub Enterprise Cloud with data residency (*.ghe.com) host
• No C:\Program Files\GitHubCopilot\managed-settings.json file, but a device MDM policy loads with bypassDisabled=false, keys=[remoteControl]
• MCP servers come from the repository .mcp.json and a repository-enabled plugin

Affected version

Copilot CLI 1.0.88

Steps to reproduce the behavior

1. On Copilot CLI 1.0.88, open a repository that defines MCP servers in .mcp.json in the GitHub Copilot app.
2. Start a new session.
3. Ask the agent to search for any of the repository's MCP tools, or inspect the session's process log.

Expected behavior

The managed-settings policy is fetched once GitHub authentication resolves, and the repository's MCP servers load according to the actual enterprise policy.

Actual behavior

No repository MCP tools are available. The process log shows (timestamps from one session, server names redacted):

18:41:52.689Z [INFO] [managedSettings] server policy fetch skipped: no authenticated GitHub host available
18:41:52.689Z [INFO] [managedSettings] effective policy resolved: source=mdm, bypassDisabled=false, serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false
18:41:55.542Z [INFO] [managedSettings] applied: bypass-permissions mode DISABLED by enterprise policy (fail-closed: policy could not be determined) - /allow-all and permission escalation are now blocked
18:41:55.542Z [DEBUG] [auth::manager_orchestration] Authentication method resolution completed {"method":"GitHubToken","authenticated":true,"failed":false}
18:41:55.699Z [DEBUG] [session::mcp::agent_host] Skipping MCP server "<server>": blocked by enterprise customization lockdown (only plugin/managed MCP servers are permitted)

The last line repeats for all 17 workspace and plugin servers. The plugin-provided server is also skipped, even though the message says plugin servers are permitted.

Between those lines, one of the three policy resolutions in the same process succeeded against the server: [managedSettings] confirmed no policy served from fresh cache (age 412044ms). So the server had confirmed no enterprise policy applies, yet the session still applied the fail-closed lockdown.

Additional context

Frequency and regression evidence

From local process logs over two days:

CLI version	Processes that logged the fail-closed fallback	Processes that also skipped MCP servers
1.0.87-0	16	0
1.0.88	5	5

The fail-closed message appeared on 1.0.87-0 without blocking MCP servers. Blocking began when sessions moved to 1.0.88. A likely related 1.0.88 change:

Enterprise managed settings now apply to sessions opened in ACP mode (copilot --acp), by AHP hosts (copilot --ahp-host), and by the published --server session, which previously ran with no managed MCP, permission, or plugin policy.

The same machine also reports Managed MCP policy settlement failed for copilot -p, with the log line no authenticated GitHub host available.

• Logs: copilot-cli-1.0.88-startup-redacted.log
• Operating system: Windows 11 Enterprise (10.0.26200)
• CPU architecture: x86_64 (AMD64)
• Terminal emulator: none. Sessions are started by the GitHub Copilot desktop app v1.1.23, not from a terminal.
• Shell: PowerShell 7.4.20 (used by the agent's shell tool; not involved in session startup)
• Other: 9 app-started processes with no recorded CLI version also logged the fail-closed fallback. 4 of those also skipped MCP servers, all between 18:16 and 18:41 UTC on 2026-09-23.