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_`.

| 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___` 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___` 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_`), or resolve `mcp__claude_ai___*` 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"] } }
```
3. In a terminal, run `claude`, ask Claude to send a test email to yourself. A permission prompt appears. Expected.
4. 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____send_message`.
5. 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.

Reproduce the mismatch with ~/.claude/settings.json in the CLI and Claude Desktop Code tab, then compare recorded tool names in ~/.claude/projects/*.jsonl and Desktop’s main.log. Check /mcp and `claude mcp list` for the connector-to-server mapping. Done means per-connector ask/deny rules match consistently across entrypoints, or the UUID mapping and mismatch warning are documented and exposed.

Written by the indexing model from the issue text.