Approving Claude desktop extensions and local MCP servers: a checklist for IT

Approving Claude desktop extensions and local MCP servers starts with one setting. An Owner switches on the desktop extension allowlist, and you then allow only the extensions you have checked. Check each one on five points: source, permissions, data access, credentials and update control. Upload your own company extensions centrally rather than passing files around by email.

The allowlist is available to Owners and Primary Owners of Claude Team and Enterprise plans. It is off by default. Until an Owner turns it on, staff can install any desktop extension in the registry. Most companies that bought Claude seats therefore start with no control over desktop extensions at all.

The allowlist governs what Claude Desktop installs. It does not stop someone editing files on their own laptop after installation. It also does not govern Claude Code, the terminal tool. This guide explains what these extensions can reach and how the allowlist works. It walks through uploading a company extension, gives you a checklist table, and sets out where the control stops.

The Model Context Protocol (MCP) is an open protocol that connects AI applications such as Claude to external data sources and tools. An MCP server is a program that speaks MCP. It offers Claude a set of tools, such as "search tickets" or "read file".

A local MCP server is an MCP server that runs on the staff member's own computer, not in the cloud. Claude Desktop starts it and talks to it directly. That is why approval matters. The program runs with the same access to the laptop as the user.

A desktop extension is a single-click installable package for a local MCP server. It replaces the older method of editing JSON configuration files and installing dependencies by hand. Desktop extensions use the .mcpb file format, short for MCP Bundle.

A connector gives Claude access to a service it cannot otherwise reach. Every connector is an MCP server. A remote connector runs on a server and Claude reaches it over the internet. A local connector arrives as an .mcpb file and runs on the laptop.

A skill is different again. A skill gives Claude know-how, meaning instructions for doing a job well, rather than access to data.

If you have not yet rolled out the app itself, start with our guide to installing Claude desktop and its admin settings.

A local MCP server can reach whatever its code is written to reach, with the user's own rights on that machine. Desktop extensions support Node.js, Python and binary MCP servers. Claude Desktop includes a built-in Node.js environment, so an extension can run without IT ever installing Node.js.

A published Linux setup guide shows the range. It runs Claude Desktop with seven local MCP servers: filesystem, excel, git, github, fetch, brave-search and podman. Between them they read and write files, open spreadsheets, work with code repositories, fetch web pages and manage containers. Each of those is a separate approval decision.

Signed-in browser sessions

Browser MCP servers deserve their own review. Playwright MCP and Chrome DevTools MCP launch a browser with a separate profile by default. Other tools, such as hangwin/mcp-chrome, reuse the user's login state. A server that drives the user's own Chrome can act inside every web app that person is signed into. Our post on Claude in Chrome for business covers the browser side.

Hand-edited configuration files

Servers added by hand live in claude_desktop_config.json. On Windows it sits at %APPDATA%\Claude\claude_desktop_config.json. On macOS it is under ~/Library/Application Support/Claude/. CloudSEK's setup guide passes a Bearer token as a header through mcp-remote in that file. Any token written there sits in a configuration file on the laptop.

Finally, content matters as much as code. A web page, email or document that Claude reads through a connector can contain instructions aimed at the AI. This is prompt injection.

The desktop extension allowlist lets an Owner choose which extensions staff may install from the in-app registry. Owners and Primary Owners of Team and Enterprise plans control it. It requires Claude Desktop version 0.13.91 or higher.

Switching it on changes four things at once:

• Users can download extensions only from the sanctioned in-app registry.
• Users can no longer drag or click to install an .mcpb file.
• Any existing desktop extension installations are force-deleted from Claude Desktop clients.
• Custom extensions you upload become available to your organisation only.

The force-delete is the part that surprises people. Warn staff before you turn it on. Check which extensions they rely on and allowlist those first. Otherwise a working setup disappears overnight and the help desk hears about it.

Machine-level policy takes priority

Enterprise policy controls set at the user-machine level override the in-app blocklist and allowlist. If your IT team already pushes Claude Desktop policies through device management, those win. For the in-app allowlist to work, isDesktopExtensionEnabled and isDesktopExtensionDirectoryEnabled must not be set to false. If either is false, the allowlist cannot populate the registry and staff see nothing to install.

The allowlist and the Claude Desktop admin settings are both documented in the Claude Help Center article on the desktop extension allowlist.

A company extension is a desktop extension you build or commission yourself and deploy to your own staff. Suppose your developer has built a local MCP server that reads tickets from Zoho Desk. Here is how it reaches the support team through the allowlist.

1. Add a manifest. The developer adds a manifest.json file to the MCP server directory with the required metadata.
2. Mark secrets as sensitive. Fields such as the API key are marked sensitive in manifest.json. Claude Desktop then encrypts them in the operating system's secure storage: Keychain on macOS, Credential Manager on Windows.
3. Package it. The developer runs the mcpb pack command, which produces a single .mcpb file.
4. Upload it. An Owner goes to Organization settings > Connectors > Desktop and uploads the file.
5. Staff install it. The extension appears in the in-app registry for your organisation only. It cannot be used by any other organisation.

Shipping an update

To release a new version, increment the version field in manifest.json and leave the name unchanged. Then upload again. Existing installs update without removing and reinstalling. If you change the name, Claude creates a second extension instead, and staff end up with two.

When Svennis builds an extension like this, we ship a read-only version first and add write tools as a later version, so each approval is a small, separate decision.

The approval checklist below gives IT and security one page per extension. Fill it in before an extension goes on the allowlist, and keep it with your other software approvals.

Check	What to ask	Where to find the evidence
Source	Who wrote it, and who maintains it? Is it a verified directory listing or a community one?	Directory label, publisher, code repository
Permissions	Which tools does it expose? Can it write, delete or send, or only read?	Tool list in the app, manifest, documentation
Data access	Which systems and folders can it reach? Does it reuse a signed-in browser?	Server code, configuration, vendor setup guide
Credentials	Where does the key or token live? Is it encrypted or in a plain config file?	Sensitive fields in manifest, claude_desktop_config.json
Update control	Does it update itself, or does someone upload each version?	Directory or private distribution
Removal	What stays on the laptop after uninstall?	Vendor uninstall notes

Third-party security grades help with the first row but do not answer it. Skills Directory, for example, gave one Calibre MCP setup skill a grade of B, scoring 84 out of 100. Its scan flagged downloads with curl or wget and packages installed at runtime. Both are worth reading. Neither replaces your own review.

Credentials are safest in the operating system's secure storage, not in configuration files. Desktop extensions that mark fields as sensitive get this automatically. Hand-configured servers often do not, as the Bearer token example above shows. The Linux setup guide takes the same line: it keeps API keys and tokens separate from all config files.

Update behaviour depends on where an extension comes from. Extensions from the official directory update automatically by default. Extensions shared privately as .mcpb files need each user to install the new file by hand. Uploading through the allowlist avoids that, because a new version with an incremented version number replaces the old one.

Automatic updates cut both ways. They bring fixes quickly. They also mean the code you approved is not the code running next month. For directory extensions that touch customer data, put a review date in your approval record.

Write access and leftovers

Good extensions make writing a deliberate choice. The Calibre MCP server needs two settings, one in Calibre and one in the MCP server, before it can write; leaving both closed keeps it read-only. Uninstalling it does not remove its shared data directory, which holds its index and models. Ask every vendor what stays behind.

Remote connectors have their own quirk. You cannot edit a custom connector's authentication after adding it. You must remove the connector and add it again.

The allowlist controls installation in Claude Desktop. Anthropic states plainly that it does not guard against people tampering with local MCP file contents after installation. A user with rights on their own laptop can still change what an approved extension does.

Several other gaps follow from how the pieces fit together:

• Machine policy wins. Device-level Enterprise policies override the in-app allowlist, so the two must agree.
• Cowork inherits local servers. Claude Desktop bridges local servers into Claude Cowork automatically, so approving one approves it there too.
• Claude Code is separate. Developers add MCP servers from the terminal with claude mcp add, outside the desktop allowlist.
• Unofficial builds are separate. Claude Desktop for Linux exists as a community Debian port, not an Anthropic release.

Claude Code's own managed setting has a gap of its own. A feature request in Anthropic's claude-code repository, issue #46296, says admins can either allow all MCP servers or block all of them. Setting allowedMcpServers to an empty list blocks plugin-provided servers too. The request was closed as not planned in June 2026.

Treat the allowlist as one layer. Device management, user rights on laptops and a short approval record make up the rest.

Choose a remote connector when the system is already reachable on the internet, and a local extension when it is not. Custom connectors are reached from Anthropic's cloud. An internal-only server therefore needs a tunnel or a desktop extension instead.

Remote connectors give admins a different set of controls. On Team and Enterprise, only an Owner can add a custom connector. Each member then signs in with their own account, so the system's own permissions still apply. Individual tools can be set to Blocked in Customize > Connectors. A cloud CRM such as Zoho CRM usually fits this pattern, as our guide to connecting Claude to Zoho CRM with MCP shows.

Local extensions suit systems on the office network or on the laptop itself. They also suit tools that should never leave the machine. The cost is that each laptop becomes a place to check.

When Svennis connects Claude to a company's programs, we build a connector, an MCP server, a plugin or a skill for each connection. We show the options with their cost, and the client chooses. The same reasoning applies to Claude with HubSpot or Salesforce via MCP.

For a UK company, approving Claude extensions is mainly a question of who holds the Owner role. On Team and Enterprise, only Owners and Primary Owners can switch on the allowlist and upload company extensions. In a small firm that is often the managing director who bought the seats. Make sure IT or your outsourced support holds that role too, or works alongside whoever does.

Many smaller UK businesses run Windows laptops without central device management. In that setting the in-app allowlist is often the only control you have. Turn it on before staff discover the registry for themselves.

Keep a simple register of approved extensions. For each one, record the checklist answers, the version you approved and the date. When a customer, auditor or insurer asks which tools can read customer records, you can answer from that register in minutes.

Finally, keep finance and support data on the strictest settings. An extension that reads tickets is a smaller risk than one that can also post replies or change invoices. Approve the read-only version first and add write access only when the team has used it for a while.

You can put basic control in place this week. Work through these steps in order:

1. Confirm who holds the Owner and Primary Owner roles on your Claude plan.
2. Check that every laptop runs Claude Desktop 0.13.91 or higher.
3. Ask staff which extensions they use, and run each through the checklist table.
4. Warn staff, then switch on the allowlist and add the approved extensions.
5. Check that no device policy sets isDesktopExtensionEnabled or isDesktopExtensionDirectoryEnabled to false.
6. Start a register with each extension, its version and its review date.

If you need a company extension for one process, such as reading tickets or CRM records, that is what Pilot Claude A, an AI agent on Claude for one process, covers. Svennis works in four steps: the Workshop, Pilot Claude A or Pilot Claude B (Claude Team for the whole team), the department Activation, then monthly operations. For seats and running costs, see our guide to what Claude for business costs and how to start.