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
- Be on an org whose Copilot policy disables 3rd-party MCP servers.
- Have custom instructions, skills, plugins and agents configured.
- Start
copilot interactively where the built-in GitHub MCP handshake stalls.
- 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.
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 agentsand never transitions to a completed state, even though everything is actually loaded (
/envlists 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
isLoadingstate until every registered participant calls.done(). Participants:instructions,skills,plugins,agents,mcp.The
mcpparticipant only calls.done()afterawait mcpHost.startServers(...)resolves (or via itsonCompletecallback, or the errorcatchbranch).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, somcp.done()is never called and the footer is stuck on "Loading:" indefinitely. Notably the footer never shows anN MCP server(s)entry (i.e.onServerConnectednever 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 forbiddenmcp./envconfirms all skills/agents/plugins/instructions are loaded and usable.Steps to reproduce
copilotinteractively where the built-in GitHub MCP handshake stalls.Loading: … skills, … agentsforever.Expected
The
mcpparticipant 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-mcpsavoids the stuck footer:startServersresolves with 0 servers, somcp.done()fires and the footer completes.