How do companies restrict which MCP servers employees can run in Claude Code, VS Code and GitHub Copilot (allowedMcpServers, deniedMcpServers, managed-mcp.json), and as an MCP server builder, how do I make my server easy for a security team to allowlist and keep allowlisted?

What should I check, step by step?

1. Publish the exact allowlist entries for your server in your docs, for example {"serverUrl": "https://mcp.example.com/*"} for the remote server and {"serverCommand": ["npx", "-y", "@example/mcp-server@1.4.2"]} for the local one, so a security team can paste them instead of guessing.

2. Keep the remote endpoint stable: one https host, the default port, and a path you don't move. In Claude Code a pattern with the hostname written in full matches only the scheme's default port, so a server on :8443 needs its own entry, and moving to a new host breaks every allowlist that names the old one.
3. Give the local server one canonical launch command. serverCommand entries match the command and every argument exactly and in order, and GitHub's reference says wildcards and command-line expansion aren't supported, so ["npx", "server"] doesn't match ["npx", "-y", "server"].
4. Decide how you want upgrades approved. A command pinned to a version (pkg@1.4.2) changes every release and needs a new allowlist entry each time, which gives the security team a review point; an unpinned command keeps matching while the code behind it changes. Say which you recommend and why.
5. Don't ask customers to allowlist you by name. Claude Code's documentation says a serverName entry is not a security control, and GitHub's says users choose server names, so use serverUrl or serverCommand to enforce identity.
6. Keep credentials out of the server definition. Claude Code's managed-mcp.json is readable by any user on the machine, and its documentation says not to store API keys in env blocks there; support OAuth, per-user headers or environment variables instead.
7. Don't rely on registry listing alone. In VS Code 1.145 and later, a server that appears in the registry but doesn't match the managed allowlist is blocked, and one that matches the allowlist but isn't in the registry is permitted unless a deny rule or MCP disablement blocks it.
8. Use a host that can't be confused with someone else's. GitHub's clients canonicalise URLs before matching (lowercase scheme and host, Punycode for Unicode host names, percent-decoded host octets, default port and fragment removed), which stops lookalike tricks from matching a pattern but doesn't make a lookalike domain safe to approve.
9. Tell users what a block looks like. Claude Code says a server blocked by policy disappears from /mcp and claude mcp list with no signal that policy is the reason, so list the error messages and the entries to request in your troubleshooting docs.
10. Re-announce changes. When your URL, port or launch command changes, publish the new allowlist entries before you switch, and keep the old endpoint serving or redirecting until customers have updated.

How do you restrict which MCP servers can run in Claude Code with managed-mcp.json, allowedMcpServers and deniedMcpServers?

Anthropic's documentation says that by default anyone running Claude Code can connect any MCP server they choose, and that while Anthropic reviews connectors against listing criteria before adding them to its directory, it doesn't security-audit or manage any MCP server. Administrators choose a pattern: disable MCP, deploy a fixed set, provide servers alongside users' own, publish an approved catalog, allow plugin servers only, use a soft allowlist, or a denylist only.

• managed-mcp.json lives at /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, and C:\Program Files\ClaudeCode\ on Windows, and is usually deployed with device management. When it's present, Claude Code loads only the servers it defines plus a few named exceptions (servers provided through managedMcpServers, in-process servers the host app registers, and Claude in Chrome if allowed), and claude mcp add fails with an "enterprise MCP configuration is active" error.
• Before loading any server, Claude Code merges the lists, checks the denylist (nothing overrides a match), then checks the allowlist. A remote server must match a serverUrl entry, and a serverName match counts only when the allowlist has no serverUrl entries; stdio servers work the same way with serverCommand. Leaving allowedMcpServers unset allows everything, while an empty array allows nothing apart from the exempt servers. To stop users broadening the list, set allowManagedMcpServersOnly to true in managed settings; denylists still merge from every scope, so users can always block a server for themselves.

How do you allowlist or block MCP servers in GitHub Copilot and VS Code with enterprise-managed settings?

GitHub's enterprise-managed settings reference defines allowedMcpServers (any server not matched is blocked; omit it to allow all; an empty array blocks everything except built-in default servers) and deniedMcpServers (blocked even if also allowlisted). It lists both keys as supported in Copilot CLI, VS Code, the GitHub Copilot app, Copilot in the cloud (sandbox) and JetBrains IDEs, and not in Copilot in the cloud on GitHub Actions.

• When several settings sources define an allowlist, the effective allowlist is their intersection, so a server must be permitted by every source; denylists are the union. First-party Copilot servers, such as the built-in GitHub MCP server, are exempt from deny rules. The reference also says the lists don't apply to MCP servers defined in repository custom agent profiles, and points to the coding agent firewall to block those.
• VS Code's enterprise AI settings page says user settings and workspace server definitions can't broaden the enterprise-managed allowlist or remove its deny rules, that commands and URLs are checked again after variable resolution, and that deny rules and setting chat.mcp.access to "none" take priority over the allowlist. It also warns that a cached GitHub registry policy isn't a startup guarantee and recommends the ChatMCP device policy for restrictions that must apply even when the policy fetch fails.

How do you make an MCP server easy for a company to allowlist?

Your server is approved by its address and launch line, not its name or its listing. In both products, the entries that actually constrain what runs are serverUrl and serverCommand, so whatever you publish as the URL and the install command becomes the identity a security team signs off on.

• Those rules check where a server is and how it's started, not what it does once running. A server at an approved URL can still change its tools after approval, so customers who need more than an address check pair the allowlist with version pinning and a check of the tool definitions before each upgrade.
• Small changes have outsized effects. A new subdomain, a non-default port, an added flag or a switch from npx to a binary each stop matching an existing entry, and in Claude Code the server then silently disappears for users. Treat these as breaking changes with notice, the same way you'd treat a removed tool.