claude.ai connectors mount under connection UUIDs in Desktop local sessions, so `mcp__claude_ai_<name>__*` permission rules never match there (re-raising #77598, closed as stale)

Preflight Checklist

• [x] I have searched existing issues. This re-raises #77598, which was closed by the stale bot on 2026-09-04 with no maintainer response. Related: #82532 (open), #58015, #56954.
• [x] I am using the latest Claude Code (2.1.263) and Claude Desktop (1.46388.4).

What's Wrong?

In Claude Desktop local sessions (Code tab, entrypoint: claude-desktop), claude.ai connectors are mounted under their connection UUID as the MCP server name. In CLI sessions of the same account, the same connectors are mounted as claude_ai_<display name>.

| Connector | CLI session (2.1.263) | Desktop local session (2.1.219 and 2.1.260) |
|---|---|---|
| Gmail | mcp__claude_ai_Gmail__send_message | mcp__00f86eb0-3a3c-4c27-acda-6f24a36b05d7__send_message |
| Google Calendar | mcp__claude_ai_Google_Calendar__create_event | mcp__4378a0e9-5968-4b33-9b01-6761445ef5f1__create_event |
| Asana | mcp__claude_ai_Asana__add_comment | mcp__67cd082d-c902-4339-b9ff-cfe96708ca78__add_comment |

Consequence: every permissions.ask or permissions.deny rule written as mcp__claude_ai_<name>__<tool> is silently ineffective in Desktop. Nothing warns about it: the rule looks valid in settings.json, no startup warning is emitted (the "rule matches no tool" check is skipped for names containing _ or *), and the tool call goes through without a prompt. Concretely, "ask": ["mcp__claude_ai_Gmail__send_message"] prompts in the CLI and sends the email without prompting in Desktop.

There is currently no supported way to write a per-connector ask/deny rule that works in Desktop:

• The docs (permissions#mcp) document only the mcp__claude_ai_<server>__<tool> form, for "connectors Claude Code fetches itself". The UUID form used by Desktop is undocumented.
• The UUID is not shown anywhere: not in /mcp, not in claude mcp list (which omits claude.ai connectors entirely), not in the Desktop connector settings. It can only be recovered from ~/.claude/projects/*.jsonl transcripts or Desktop's main.log.
• Organization connector tool controls set to ask do not reach Desktop local/SSH sessions (documented in mcp#organization-controls-on-connector-tools); only blocked does, and blocked also removes the tool from claude.ai chat.
• A server-segment glob (mcp__*__send_message, or the UUID-shaped mcp__*-*-*-*-*__send_message) works for ask/deny but loses per-connector granularity: since ask always wins over allow regardless of specificity, two connectors with the same tool name can no longer be treated differently.

This matters for teams that distribute a recommended settings.json with ask rules for outbound actions (send email, create calendar event, delete task). The rules give a false sense of protection to everyone who works in the Desktop app.

What Should Happen?

Any one of these would resolve it:

1. Mount connectors under the same server name in every entrypoint (claude_ai_<name>), or resolve mcp__claude_ai_<name>__* rules against the UUID-mounted server in Desktop as an alias.
2. Failing that, document the UUID form and expose the display name to UUID mapping in /mcp and claude mcp list, so rules can be written deliberately.
3. Emit a startup warning when a mcp__claude_ai_* rule exists but no server with that name is mounted in the session, so the mismatch is at least visible.

Error Messages/Logs

No error is produced; that is the problem. Evidence from transcripts on one macOS machine, same account, same connectors:

2026-08-04  entrypoint=claude-desktop  version=2.1.219  uuid-named tools=522   claude_ai-named tools=0
2026-08-04  entrypoint=claude-desktop  version=2.1.219  uuid-named tools=522   claude_ai-named tools=0
2026-09-04  entrypoint=claude-desktop  version=2.1.260  uuid-named tools=1602  claude_ai-named tools=0
2026-09-04  entrypoint=claude-desktop  version=2.1.260  uuid-named tools=1068  claude_ai-named tools=0
2026-09-04  entrypoint=claude-desktop  version=2.1.260  uuid-named tools=1602  claude_ai-named tools=0
2026-09-08  entrypoint=cli             version=2.1.263  uuid-named tools=0     claude_ai-named tools=605
2026-09-08  entrypoint=cli             version=2.1.263  uuid-named tools=0     claude_ai-named tools=640

The Gmail UUID 00f86eb0-3a3c-4c27-acda-6f24a36b05d7 is identical on 2026-08-04 and 2026-09-04, across the 2.1.219 to 2.1.260 upgrade, so the UUID is stable for a given connection in this case. #82532 reports that it can also rotate without a reinstall.

Desktop ~/Library/Logs/Claude/main.log shows the same UUID-named tool calls, for example mcp__661701d8-b3ee-4ee0-82b5-715f14e7aa31__get_account in session local_….

Steps to Reproduce

1. In claude.ai, connect the Gmail connector (or any connector with an outbound tool).
2. Add to ~/.claude/settings.json:

``json
{ "permissions": { "ask": ["mcp__claude_ai_Gmail__send_message"] } }
``

1. In a terminal, run claude, ask Claude to send a test email to yourself. A permission prompt appears. Expected.
2. In Claude Desktop, Code tab, start a local session in any folder (Manual or Auto mode), ask Claude to send a test email to yourself. No prompt; the email is sent. The transcript in ~/.claude/projects/ shows the call as mcp__<uuid>__send_message.
3. For comparison, mcp__*__send_message (glob in the server segment) is documented to match every server in ask rules and should prompt in Desktop too. We have verified the glob semantics in the CLI only (see Additional Information), not in Desktop.

Claude Model

Not model dependent; this is the permission layer, not model behavior.

Is this a regression?

No, not as far as we can tell. A commenter on #77598 reports the UUID mounting already on 2.1.175.

Claude Code Version

2.1.263 (CLI), Claude Desktop 1.46388.4. Also observed with 2.1.219 and 2.1.260 in Desktop.

Platform

Claude Desktop (Code tab, local sessions) and CLI

Operating System

macOS 26.5.2

Additional Information

• Verified glob semantics in the CLI with --permission-mode dontAsk (where a matching ask rule denies): mcp__*__search_emails in ask denied a call to a local server proton-bridge; mcp__*-*-*-*-*__search_emails did not, so the UUID-shaped glob targets only UUID-mounted servers. Not verified in Desktop yet.
• The docs page for Desktop states that no MCP setting or managed-mcp.json reaches connectors in local/SSH sessions and points to organization connector tool controls, but those controls only support blocked for Desktop. Permission rules in settings.json are therefore the only remaining lever for "ask before sending", and they need a name they can match.