[FEATURE] MCP servers should register with descriptive names in macOS Privacy & Security

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude Code MCP servers request macOS permissions (e.g. Calendar, Contacts, Reminders), each subprocess registers as "claude" in System Settings → Privacy & Security. Over time, this creates a long list of identical "claude" entries with no way to differentiate them.

On my machine, I currently have 10 separate "claude" entries under Calendars, all showing "Full Access". I cannot tell which entry corresponds to which MCP server, which are from current sessions vs stale old ones, or which are safe to remove.

This causes real problems:

• When a permission issue occurs (e.g. macOS Sequoia changed Calendar permissions from "Authorized" to "WriteOnly"), I cannot identify which specific "claude" entry to fix
• I cannot clean up stale permission grants from old sessions without risking breaking a working one
• Debugging permission failures requires toggling all entries or granting blanket access, which defeats the purpose of granular permissions

Proposed Solution

MCP server subprocesses should register with descriptive application identifiers when requesting macOS permissions, rather than inheriting the generic "claude" name. For example:

• "Claude Code - Calendar MCP" instead of "claude"
• "Claude Code - Reminders" instead of "claude"
• "Claude Code - Contacts" instead of "claude"

Alternatively, consolidate permission requests so that a single "Claude Code" entry covers all MCP server subprocesses, rather than each subprocess creating its own grant.

Alternative Solutions

Currently I work around this by granting Full Access to every "claude" entry and hoping one of them is the right one. This is not ideal from a security perspective and makes troubleshooting permission failures time-consuming.

The underlying MCP servers use Python's EventKit framework via PyObjC, which inherits the parent process identity. A possible implementation path would be setting LSApplicationCategoryType or a custom CFBundleIdentifier on the subprocess, though I recognise macOS sandboxing makes this non-trivial.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

1. User has a system with a Calendar MCP server using EventKit
2. macOS Sequoia changes the permission model — EventKit now returns status 4 (WriteOnly) instead of 3 (FullAccess)
3. Calendar queries silently fail with "Calendar access denied"
4. User opens System Settings → Privacy & Security → Calendars
5. They see 10 identical "claude" entries, all showing "Full Access"
6. They have no way to identify which entry is the Calendar MCP server
7. The only option is to toggle all entries off and back on, or remove all and re-grant — losing track of which components need what access
8. With descriptive names, they could immediately identify "Claude Code - Calendar MCP" and fix just that entry

Additional Context

This issue affects all macOS permissions that MCP servers might request — Calendar, Contacts, Reminders, Location, etc. As the MCP ecosystem grows and users run more servers, this problem will get worse.

Related: the macOS Sequoia permission model change (status 3 → status 4 for Calendar EventKit access) is a separate issue but was the trigger that exposed how unmanageable the undifferentiated "claude" permission entries are.