When the xcode-tools MCP server is configured (xcrun mcpbridge), macOS repeatedly shows the TCC dialog:
Allow “cursor-vscode” to access Xcode?
Clicking “Allow” does not persist reliably. The prompt reappears on restart, and sometimes multiple times per session as different Cursor Helper (Plugin) processes each trigger their own prompt.
Root Cause
The mcpbridge process is spawned as a child of “Cursor Helper (Plugin)”, which has two issues:
Generic bundle ID — The helper uses com.github.Electron.helper (the default Electron helper identifier) instead of a Cursor-specific bundle ID. macOS TCC cannot reliably distinguish it from any other Electron app’s helper process.
Missing entitlement — The main Cursor.app binary has the com.apple.security.automation.apple-events entitlement, but “Cursor Helper (Plugin)” does not. This is the entitlement macOS checks when a process tries to send Apple Events to another app.
Evidence:
# Main Cursor app — has the entitlement:
codesign -d --entitlements - "/Applications/Cursor.app"
# → com.apple.security.automation.apple-events = true
# Helper Plugin — missing it:
codesign -d --entitlements - "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"
# → only has allow-jit, allow-unsigned-executable-memory, disable-library-validation
# Bundle ID is generic Electron:
defaults read "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app/Contents/Info.plist" CFBundleIdentifier
# → com.github.Electron.helper
Suggested Fix
Give “Cursor Helper (Plugin)” a unique bundle ID (e.g., com.todesktop.230313mzl4w4u92.helper).
Add the com.apple.security.automation.apple-events entitlement to its code signature.
This would let macOS record the TCC approval once, matched to a stable identity, and never re-prompt.
Steps to Reproduce
Install Cursor 3.1.15 (or later) on macOS.
Install Xcode 26.x and ensure xcrun mcpbridge is available.
Open (or create) a project with the following .cursor/mcp.json:
{
“mcpServers”: {
“xcode-tools”: {
“command”: “xcrun”,
“args”: [“mcpbridge”]
}
}
}
Open the project in Xcode so that a workspace/project is active.
Open the same project in Cursor.
Observe: macOS displays the TCC dialog “Allow cursor-vscode to access Xcode?”
Click “Allow”.
Quit and reopen Cursor (or wait for Cursor to auto-update).
Observe: the same TCC dialog appears again.
Expected Behavior
Clicking “Allow” once should permanently grant permission. The dialog should not reappear unless the user manually revokes it in System Settings > Privacy & Security > Automation.
Thanks for the incredibly thorough report — your root cause analysis and evidence are spot on.
We’ve confirmed the entitlement gap you identified. The Cursor Helper (Plugin) process is indeed missing the Apple Events automation entitlement, which means macOS can’t persist TCC approvals for any child process it spawns (like MCP servers that interact with Xcode). The generic Electron bundle ID compounds the issue.
This is a known issue class that also affects other workflows involving Apple Events from Cursor — this earlier thread and this one report the same underlying gap from different angles.
Our team is aware and this needs a packaging-level fix. Unfortunately there’s no user-side workaround for the repeated prompts — clicking “Allow” each time is the only option until the fix ships. We’ll follow up here when there’s progress.
Hey @tpaul,
We’ve been investigating the TCC prompt issue internally and want to make sure our engineering ticket is as actionable as possible.
We were able to confirm that MCP servers spawned by Cursor do trigger TCC prompts when sending Apple Events (tested with Safari, Calendar, and Keynote). However, in our testing on macOS 26.4, clicking “Allow” persisted the permission across Cursor restarts – the prompts did not reappear.
To help us narrow down why the prompts aren’t persisting for your team, could you (or one of the affected engineers) provide:
A short screen recording showing the TCC prompt reappearing after a Cursor restart
macOS version (exact build – sw_vers in Terminal)
Whether the Macs are MDM-managed – some MDM profiles enforce TCC policies that can prevent permissions from persisting
What shows in System Settings > Privacy & Security > Automation for Cursor after clicking “Allow” – does Cursor appear in the list, and is Xcode toggled on?
This will help us understand whether the issue is specific to xcrun mcpbridge / Xcode, or related to your enterprise device management configuration.
A short screen recording showing the TCC prompt reappearing after a Cursor restart
Unable to get a screen recording at the moment, but it pops up multiple times in a row with multi-agent usage. Having to click allow several times in a row. Next time it happens I’ll come back and provide a recording. Figured you’d want this info asap
macOS version (exact build – sw_vers in Terminal)
ProductName: macOS
ProductVersion: 26.4.1
BuildVersion: 25E253
Whether the Macs are MDM-managed – some MDM profiles enforce TCC policies that can prevent permissions from persisting
We are MDM managed
What shows in System Settings > Privacy & Security > Automation for Cursor after clicking “Allow” – does Cursor appear in the list, and is Xcode toggled on?
Thanks for the detailed info, @Vincent_Romani. This matches the pattern we’re tracking – the Cursor Helper (Plugin) process that spawns MCP servers is missing a macOS entitlement needed for TCC to persist Apple Events approvals. Each helper process gets a separate prompt because macOS can’t match them to a single persistent identity.
The fact that Xcode is toggled on in your Automation settings confirms macOS is recording the approval at one level, but the individual helper processes still trigger their own prompts.
Unfortunately, there’s no user-side workaround right now – clicking “Allow” each time is the only option until we ship a packaging fix. Our engineering team is tracking this.
