MCP tools in permissions allowlist are still prompting for approval every time

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

In the Cursor CLI, adding MCP tools to the permissions.allow allowlist
has no effect. Every time the agent calls an MCP tool, it still asks me to approve, even though the tool is explicitly allowlisted.

Steps to Reproduce

  1. Configure an MCP server (in my case a server named serial).
  2. In ~/.cursor/cli-config.json, add MCP entries to the allowlist:
    "permissions": {
  "allow": [
    "Mcp(serial:*)",
    "Mcp(serial:close)",
    "Mcp(serial:open)",
    "Mcp(serial:read)",
    "Mcp(serial:write)"
  ],
  "deny": []
},
"approvalMode": "allowlist"
  3. Run the agent and let it call any of the serial MCP tools.

Expected Behavior

Allowlisted MCP tools run without an approval prompt (same as allowlisted Shell(...) commands, which work correctly).

Operating System

Linux

Version Information

CLI Version 2026.06.26-7079533
Model Opus 4.8 300K High
Subscription Tier Team
OS linux (x64)
Terminal vscode
Shell bash
User Email [email protected]

For AI issues: which model did you use?

claude opus 4.8

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Thanks for the detailed report and reproduction steps. We confirmed that Mcp(serial:*) is valid and that this is a bug in how the CLI handles permission precedence for team members. We are tracking it internally.

As a temporary workaround, you can set approvalMode to "unrestricted". This grants much broader execution permissions, so please use it only if that is acceptable for your environment. Otherwise, manual approval is currently required.

We will update this thread when a fix is available.

9

@Lai_Jinyi Thanks very much for reporting, I just wanted to update you that we’ve merged a fix for this, and it will be live in the next release version of the CLI.

10

Hi, I am also encountering this issue on version 2026.07.13-7fe37d2 (lab channel).

I found that mine is caused by a team admin setting where allowedMcpServers is set. There seems to be logic where if team controls are set, ONLY the team allowlist is used and the personal allowlist is ignored. However, if I set approvalMode to "unrestricted" as suggested above, it still works.

I find this behavior confusing. If there is a team-admin controlled allowlist, why can I circumvent it with a local config change with "unrestricted"? And if I am able to do that, why can’t I set it to consult my personal allowlist instead?

Is this a bug or intended?

As a workaround, I managed to patch my local index.js with:

 if (teamControlsEnabled) {
   if (inTeamAllowlist) return ALLOW;
-} else {
-  if (inPersonalAllowlist) return ALLOW;
 }
+if (inPersonalAllowlist) return ALLOW;

so it falls back on the personal allowlist. This works.

The other unintuitive behavior I found is that this only happens if there is at least one entry under allowedMcpServers where the name field is specified. If none of the entries have a name, then it already falls back on the personal allow list. If even a single entry includes name the personal allowlist for ALL users is ignored.