Xcode MCP tools requiring Automation permission hang indefinitely for CLI clients without bundle identifiers

Description

Xcode 26.3's native MCP server exposes tools like RenderPreview, BuildProject, ExecuteSnippet, GetTestList, and RunSomeTests that require macOS Automation (AppleEvents/TCC) permission. When invoked from Claude Code CLI, these tools hang indefinitely because macOS cannot persist the Automation permission for CLI tools that lack a stable bundle identifier.

Steps to Reproduce

1. Configure Xcode 26.3's MCP server in .claude.json per Apple's documentation
2. Open a project in Xcode
3. From Claude Code CLI, call any tool that triggers Xcode automation (e.g., mcp__xcode__RenderPreview)
4. macOS shows the "Allow claude-code to access Xcode" TCC dialog
5. Click "Allow"

Expected Behavior

Permission persists. Subsequent calls to RenderPreview/BuildProject/etc. work without re-prompting.

Actual Behavior

• The "Allow" click does not persist in System Settings > Privacy & Security > Automation (no claude-code entry appears)
• The tool call hangs indefinitely (waited 14+ minutes) and eventually the MCP connection dies with Connection closed
• On next session, the permission dialog reappears
• Read-only tools (XcodeLS, XcodeRead, XcodeGrep, XcodeListNavigatorIssues, DocumentationSearch) work fine — only tools that trigger Xcode to build/execute are affected

Root Cause

Claude Code runs as a Node.js process from a versioned path (~/.local/share/claude/versions/X.Y.Z). macOS TCC (Transparency, Consent, and Control) persists Automation permissions by app bundle identifier. CLI tools without a proper macOS bundle identifier cannot be reliably fingerprinted by TCC, so:

1. The permission dialog appears but "Allow" doesn't stick
2. The underlying AppleEvent may never actually get authorized, causing the tool to hang

This is the same class of issue as flutter/flutter#141624 (Xcode automation permission fails with "AppleEvent timed out").

Impact

This blocks the highest-value tools in the Xcode MCP integration:

• RenderPreview — visual SwiftUI preview feedback loop (the headline feature for UI development)
• BuildProject — Xcode-native builds
• ExecuteSnippet — running code in project context
• RunSomeTests / GetTestList — test execution

Without these, the Xcode MCP integration is limited to read-only file operations (which Claude Code's native tools already handle) plus DocumentationSearch and structured diagnostics.

Environment

• macOS 26.2 (Tahoe)
• Xcode 26.3 RC
• Claude Code 2.1.32
• Terminal: Warp (also tested concept — terminal app shouldn't matter since the TCC dialog identifies claude-code specifically)

Possible Solutions

1. Wrap Claude Code in a proper macOS app bundle with a stable bundle identifier so TCC can persist permissions
2. Use a stable, well-known path for the Claude Code binary (not versioned) so TCC can fingerprint by path
3. Document the limitation and provide a workaround (e.g., manually adding TCC entries via tccutil or MDM profiles)
4. Coordinate with Apple since Xcode MCP was designed for exactly this use case — external agents controlling Xcode

Workaround Attempted

• Clicking "Allow" on the macOS dialog — does not persist
• Checking System Settings > Privacy & Security > Automation — no entry appears for claude-code
• tccutil reset AppleEvents com.anthropic.claude-code — "No such bundle identifier"
• Restarting Claude Code and Xcode — same behavior