`permissions.json` MCP wildcard allowlist entries are not honoured, while exact entries execute

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

MCP wildcard entries in ~/.cursor/permissions.json are not being honoured.

Wildcard-covered tools still show approval prompts and log needsApproval (not in allowlist). Exact MCP entries appear to execute without prompting, even though the permission log still reports needsApproval.

{
  "mcpAllowlist": [
    "honeycomb:get_*",
    "honeycomb:refinery_docs",

    "aws-managed-mcp:aws___*",
    "aws-managed-mcp:aws___list_regions",
    "aws-managed-mcp:aws___search_documentation"
  ]
}

The docs say mcpAllowlist supports server:*, *:tool, *:*, and glob-style patterns such as my-server:list_*.

aws-managed-mcp:aws___*, was added to test this specific behaviour and is not part of my normal allowlist

Steps to Reproduce

This is likely to be difficult to reproduce - I suspect it’s something “stuck” in my client, similar to MCP Allowlist doesn't work, also can't be edited .

In any case, I reproduce it by:

  1. restarting cursor, and making sure that all cursor-related processes had been killed
  2. ensuring MCPs were loaded and active, ensuring that security mode is “Allowlist (with Sandbox)” and the settings UI is showing that allowlist & approval behaviour is managed by ~/.cursor/permissions.json
  3. instructing the agent to perform MCP calls that matched wildcards and calls that matched exact entries
  4. analysing logs on the items that worked and the ones that still prompted.

Expected Behavior

Wildcard & non-wildcard permissions.json entries match consistently.

What actually happened:

Wildcard-covered tools prompt and are blocked if I choose Skip.

Current log examples:

2026-07-03 11:07:39.193 [info] [permissions-service] shouldBlockMcp: toolName="get_workspace_context", providerIdentifier="honeycomb"
2026-07-03 11:07:39.194 [info] [permissions-service] shouldBlockMcp: needsApproval (not in allowlist) toolName="get_workspace_context", providerIdentifier="honeycomb", approvalMode="allowlist"

2026-07-03 11:09:45.887 [info] [permissions-service] shouldBlockMcp: toolName="aws___retrieve_skill", providerIdentifier="aws-managed-mcp"
2026-07-03 11:09:45.887 [info] [permissions-service] shouldBlockMcp: needsApproval (not in allowlist) toolName="aws___retrieve_skill", providerIdentifier="aws-managed-mcp", approvalMode="allowlist"

Renderer log confirms the approval prompt:

2026-07-03 11:07:39.217 [info] [ComposerWakelockManager] Released wakelock id=8 reason="user-approval-requested"
2026-07-03 11:09:45.909 [info] [ComposerWakelockManager] Released wakelock id=12 reason="user-approval-requested"

Exact entries behave differently. They also log needsApproval, but execute anyway without a visible prompt:

2026-07-03 11:08:45.172 [info] [permissions-service] shouldBlockMcp: toolName="refinery_docs", providerIdentifier="honeycomb"
2026-07-03 11:08:45.921 [info] [permissions-service] shouldBlockMcp: needsApproval (not in allowlist) toolName="refinery_docs", providerIdentifier="honeycomb", approvalMode="allowlist"

Request trace for the exact honeycomb:refinery_docs call:

2026-07-03T01:08:46.061Z span_started name="workbench_toolset.execute"
2026-07-03T01:08:47.320Z span_completed name="workbench_toolset.execute"

Exact AWS entry also executed:

2026-07-03 11:07:56.303 [info] [permissions-service] shouldBlockMcp: toolName="aws___list_regions", providerIdentifier="aws-managed-mcp"
2026-07-03 11:07:56.304 [info] [permissions-service] shouldBlockMcp: needsApproval (not in allowlist) toolName="aws___list_regions", providerIdentifier="aws-managed-mcp", approvalMode="allowlist"

2026-07-03T01:07:56.415Z span_started name="workbench_toolset.execute"
2026-07-03T01:08:02.730Z span_completed name="workbench_toolset.execute"

Historical Evidence

The same machine previously logged successful wildcard matches, so this is not a case where wildcard support never existed.

Historical log from 23 Jun showed entries like:

matchesMcpEntry: serverPattern="honeycomb", toolPattern="get_*", normalizedToolName="get_workspace_context", result=true
ALLOWED (explicitly in allowlist)

and:

matchesMcpEntry: serverPattern="prometheus", toolPattern="*", normalizedToolName="executequery", result=true
ALLOWED (explicitly in allowlist)

In the current broken state, I do not see matchesMcpEntry for the failing wildcard checks. The permission service goes straight to needsApproval (not in allowlist).

Operating System

MacOS

Version Information

Cursor 3.9.16 stable, Glass layout
From logs: client_version="3.9.16"

For AI issues: which model did you use?

Composer 2.5, GPT 5.5 XHigh to investigate & compile this report.

For AI issues: add Request ID with privacy disabled

492cdd24-7de5-41d3-b979-dcdb7836b0da

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey there!

Your config is correct, and this isn’t a wildcard-matching problem. This is a known regression we’ve already fixed on our end. A recent change caused Cursor to skip your personal ~/.cursor/permissions.json allowlist whenever there’s no team/admin MCP allowlist that should take precedence — so your entries (both wildcard and exact) weren’t being consulted at all. That’s exactly why the matcher stopped running for the failing checks and everything dropped straight to “needs approval.”

The reason a couple of exact tools still ran is a bit of a red herring: those specific tools had already been approved earlier in that session, so they executed from that session approval rather than from permissions.json. It wasn’t that exact entries were honored and wildcards weren’t — neither was being read.

This also isn’t the older “stuck client” behavior you linked, so there’s no reset or reinstall needed. The fix is client-side and already merged, but it isn’t in a downloadable build just yet (your 3.9.16 predates it) - it’ll land in an upcoming update. I’ll follow up here as soon as the fixed version is available to grab.

In the meantime, approving a tool when it prompts will let it run without re-prompting for the rest of that session, though that won’t stick across restarts until you’re on the fixed build.

8

Hi Mohit - by “session”, do you mean a particular chat thread?

In the request ID I’ve shared that’s a fresh thread - so there’s no previous approvals.

I’m not 100% sure, but I also remember hitting “approve” and it still asking.

What cursor did find when investigating was a series of things approved in the state file - 23 items, unchanging - it’s possible those “exact” items were in that list.