Environment footer stuck on "Loading:" forever when built-in GitHub MCP handshake stalls under org MCP policy

[cryptonic7-tech]

Version

GitHub Copilot CLI 1.0.73 (macOS, Node v24.16.0)

Summary

The environment status footer permanently shows

◎ Loading: 1 instruction, 40 skills, 1 plugin, 2 agents

and never transitions to a completed state, even though everything is actually loaded (/env lists all instructions, skills, plugins and agents correctly). It is purely a cosmetic / never-resolving indicator, but it makes the CLI look like it is stuck loading forever.

Root cause (from the bundled index.js)

The footer's loading indicator uses a participant registry that stays in isLoading state until every registered participant calls .done(). Participants: instructions, skills, plugins, agents, mcp.

The mcp participant only calls .done() after await mcpHost.startServers(...) resolves (or via its onComplete callback, or the error catch branch).

When 3rd-party MCP is disabled by org policy and the built-in remote GitHub MCP server (github-mcp-server) handshake never resolves, none of those paths run, so mcp.done() is never called and the footer is stuck on "Loading:" indefinitely. Notably the footer never shows an N MCP server(s) entry (i.e. onServerConnected never fires).

Evidence (from my logs)

• Third-party MCP servers are disabled by your organization's Copilot policy. Only built-in servers are available.
• [ERROR] GitHub MCP server configured after authentication
• [WARNING] Failed to create Mission Control session: 403 forbidden
• Footer lists instruction / skills / plugin / agents but never mcp.
• /env confirms all skills/agents/plugins/instructions are loaded and usable.

Steps to reproduce

1. Be on an org whose Copilot policy disables 3rd-party MCP servers.
2. Have custom instructions, skills, plugins and agents configured.
3. Start copilot interactively where the built-in GitHub MCP handshake stalls.
4. Observe the bottom footer stays on Loading: … skills, … agents forever.

Expected

The mcp participant should call .done() on a timeout / policy-disabled / failed-handshake path, so the footer clears regardless of MCP startup outcome.

Workaround

Launching with --disable-builtin-mcps avoids the stuck footer: startServers resolves with 0 servers, so mcp.done() fires and the footer completes.

[zrivkis]

I am experiencing the exact same issue, but without 3rd party MCP servers being disabled by org policy.

Version

GitHub Copilot CLI 1.0.73 (Windows, Node 26.4.0)

Summary

The environment footer is permanently showing
Loading: 33 skills or Loading: 33 skills, 2 MCP servers
depending if mcp-config.json is present or not.

Built-in Github MCP server is hit or miss. Sometime it loads, sometimes it doesn't.
Custom Github MCP server gets stuck on "Server connecting" when things don't work. However, successfully authenticates and loads the built-in server when things do "work" without making any changes to the configs.

Evidence

Works.log
DoesntWork2.log
DoesntWork1.log

Workaround

Using /restart multiple times can eventually resolve the issue. Using /login resolves the issue every time, however, not practical.

Broken State

Working State (after /restart or /login)

[BoykaHe]

Copilot CLI 1.0.73 has an intermittent issue with the built-in GitHub MCP initialization/environment loading state machine. After successful authentication, the built-in MCP sometimes fails to complete registration or startup, yet does not time out and exit, causing the mcp participant to remain in a "pending" state indefinitely. This ultimately results in a persistent "Loading:" message at the bottom of the screen:

[gokhanarkan]

Triage summary

Your analysis of the bundled code lines up with what we found in the current source: src/cli/hooks/useMcp.ts only guarantees the mcp loading participant completes via a 15-second safety-net timeout, and that timeout is registered only when a GitHub token is already available and the server is not user-configured or disabled at that point in startup (expectGitHubServer). Under your org-policy-plus-stalled-handshake scenario, the built-in GitHub MCP server can end up outside that guarded path, so nothing calls done() for it.

Two other reports in this issue (2026-07-22, 2026-07-23) describe similar built-in GitHub MCP startup stalls, one without org policy involved, which suggests the underlying stall may be broader than just the policy case.

Recommended fix: make the safety-net completion guarantee unconditional whenever the mcp participant is registered at all, not gated on the token/config preconditions, so any stalled handshake clears the footer within a bounded time.

Route: agent-ready.

This triage summary was prepared with GitHub Copilot and reviewed before posting.