macOS permissions are confusing because desktop control spans multiple process identities

[AmrDab]

Summary

On macOS, the current permissions experience for desktop control is confusing because Clawd Cursor operations appear to span multiple process identities instead of one clear app identity.

Users expect to grant access once to "Clawd Cursor" and be done. In practice, they may need to enable permissions for a mix of Terminal, node, OpenClaw, OpenClaw Gateway, AE server, or other helpers, and it is not obvious which one is actually responsible for the failing operation.

What is happening

macOS grants Screen Recording and Accessibility permissions per app/process identity, not per project folder or codebase.

In the current setup, desktop control may run through a combination of:

• Terminal or iTerm
• node
• OpenClaw / OpenClaw Gateway style background services
• helper processes

That means a user can grant access to one visible host, but the actual screen or control action may be happening in another process, so the product still fails with a permission error.

Why this is a problem

From the user perspective, this feels arbitrary and broken:

• they enable Terminal, but screen capture still fails
• they are not told clearly which app entry to enable
• they may need a full restart, but the product does not make that obvious
• the result is a frustrating first-run experience even when the underlying automation works

Suggested short-term improvements

At minimum, the CLI should:

1. Detect the actual host process chain involved in desktop control
2. Print the exact macOS app names the user should enable
3. Clearly distinguish between:
   • Accessibility for clicking, typing, control
   • Screen Recording for visual perception
4. Tell the user when a full restart is required
5. Avoid vague messaging like "grant permission" without naming the specific host apps/processes

Suggested long-term direction

The clean fix is architectural: move desktop automation behind a single macOS app identity, for example Clawd Cursor.app.

Recommended model:

• A real Clawd Cursor.app becomes the trusted desktop host
• That app owns:
  • Screen Recording
  • Accessibility
  • automation helpers
• The CLI becomes a thin client that communicates with the app
• All screen capture and control flows happen inside the app process, or a tightly controlled bundled helper

This would let users do the obvious thing:

Grant permissions to Clawd Cursor.app

instead of guessing between Terminal, node, helper processes, or background services.

Incremental implementation path

Rather than converting the entire product into a full GUI app immediately, a pragmatic path would be:

1. Build a lightweight macOS host app, menu bar app is fine
2. Move screen capture and accessibility-dependent operations into that app
3. Let the existing CLI communicate with the host app over local IPC
4. Keep the current CLI workflow, but make the app the single permission-bearing identity
5. Later, sign, notarize, and distribute the host app as the official desktop runtime

Why this matters

This is not just polish. It directly affects onboarding, trust, and usability. Right now the permission model makes the product feel harder than it is. A single app identity, or at least much clearer process-aware guidance, would make the macOS experience dramatically better.

[m13v]

this is one of the most painful parts of building desktop control tools on macOS. the core problem is that TCC (Transparency, Consent, and Control) binds permissions to the specific code signing identity of the process that makes the system call, not to the "project" or the parent process.

so if your node helper spawns a subprocess that calls CGDisplayCreateImage or AXUIElementPerformAction, macOS checks the subprocess identity, not node's. and if that subprocess is a raw binary without a proper bundle ID, it might not even show up in System Settings at all.

what helped us: detect the full process chain at startup and emit a clear checklist of which exact entries the user needs to enable. on macOS 26+ (Tahoe) it gets worse because unbundled binaries are now completely invisible to the TCC prompt, so you may need to wrap helpers in minimal .app bundles. also worth checking CGPreflightScreenCaptureAccess() programmatically so you can tell the user exactly which permission is missing rather than just failing silently.

[m13v]

our MCP server for macOS desktop automation that handles the TCC permission chain for accessibility and screen recording across process identities: https://github.com/mediar-ai/mcp-server-macos-use/blob/main/Sources/MCPServer/main.swift

includes the CGPreflightScreenCaptureAccess check and the AXUIElement permission validation pattern.