VS Code closes a gap that let failed MCP policy syncs fail open
Version 1.145 lets a managed allowlist approve MCP servers outside the registry, and fixes a bug where a failed policy refresh silently lifted registry-only restrictions.
VS Code 1.145, released on 4 November, changes how organisations control which MCP servers can run. An enterprise-managed allowedMcpServers list now takes precedence over a registry-only policy, so admins can approve a server for everyone without first publishing it to their internal registry. Previously, a server the allowlist approved but that wasn’t in the registry was blocked outright; now it runs if it matches the list, and a registry server that doesn’t match is blocked instead.
The same release fixes a separate bug in that registry-only enforcement: if a policy refresh failed, from a network error or rate limiting, VS Code dropped the restriction entirely until the next refresh succeeded, rather than keeping the organisation’s last known policy. It now holds onto that last known state and only clears it once GitHub confirms no registry applies. Elsewhere, 1.145 adds cron scheduling for local agent automations and lets the Agents window preview canvases from a remote agent session without leaving the editor.
Why it matters: anyone running VS Code under Copilot’s MCP governance policies previously had a window, however brief, where a flaky connection meant any MCP server could run unrestricted. That’s now closed, and the new allowlist precedence removes one reason teams were avoiding central registry approval in the first place.
The caveat: this only covers MCP servers VS Code itself starts, not ones managed by the Agent Host, and deniedMcpServers or disabling MCP outright still override the allowlist either way.