name: hd-permissions-mac description: > macOS platform companion to hd-permissions — the Apple-specific half of the permission story. The generic skill (adom/hd-bootstrap) covers HD's webview auto-grant: inside HD a webview app NEVER sees a "site wants to use your microphone/camera/clipboard/location" prompt. THIS skill carries only what's macOS-specific: the OS-level TCC privacy model (Screen Recording, Accessibility, Automation, Camera, Microphone) granted under System Settings → Privacy & Security, how HD preflights/requests them (CGPreflightScreenCaptureAccess, AXIsProcessTrustedWithOptions), and that some need a relaunch / a stable signing identity to stick. Mirror of hd-permissions-windows (UAC, no per-feature gate). Trigger words — macos permissions, TCC, screen recording permission, accessibility permission, automation permission, privacy and security, AXIsProcessTrusted, CGPreflightScreenCaptureAccess, grant accessibility, relaunch to take effect.

hd-permissions (macOS) — the TCC privacy gates

This is the macOS half of hd-permissions. The cross-platform contract — HD's webview auto-grant (mic/camera/clipboard/geolocation/notifications/sensors all ALLOW, so no in-page "site wants to use…" prompt) — is identical on every host and lives in the generic hd-permissions skill. Read that first; this skill only covers the macOS OS-level gates that sit separately underneath that auto-grant.

Two different layers — don't conflate them

  • In-webview permissions (mic/camera/clipboard/etc.): on macOS HD's webview is WKWebView, which grants in-page media capture with no per-site prompt — same user-facing result as the Windows WebView2 PermissionRequested auto-grant. This is the generic skill's territory.
  • OS-level TCC permissions: macOS still gates HD's process with the system-wide TCC (Transparency, Consent & Control) model. These are real system prompts and live under System Settings → Privacy & Security. The webview auto-grant does NOT bypass them — if HD's process is denied Camera/Mic/Screen Recording at the OS, the in-page capture still fails (look here, not at a "denied prompt", per the generic skill).

The TCC gates HD touches (and how it preflights them)

HD requests/preflights these natively (mac_input.rs, exposed as Tauri commands in lib.rs):

TCC permission What HD uses it for How HD checks/requests
Accessibility synthesize keystrokes / AXPress into another app (press Return on Safari's claude.ai Authorize page) to auto-approve OAuth AXIsProcessTrustedWithOptions via accessibility_trusted(prompt)macos_accessibility_status
Screen Recording screenshot the consent window for the OCR-approve flow CGPreflightScreenCaptureAccess (non-prompting) / CGRequestScreenCaptureAccess via screen_capture_trusted(prompt)macos_screen_recording_status
Automation ("control System Events") the AppleScript/System-Events button-press that approves OAuth prime_automation / prime_browser_automationmacos_prime_automation, macos_prime_browser_automation
Camera / Microphone the first time HD's process actually uses the device one-time system TCC prompt; toggles must be ON for Hydrogen Desktop under Privacy & Security

Preflight (CGPreflight…, AXIsProcessTrusted… with prompt=false) is non-prompting — it reports current state. Passing prompt=true shows the system dialog the first time and adds HD to the relevant Privacy & Security list. HD frontloads Accessibility (and the Automation consent) in the pre-login gate rather than mid-cascade (setup_steps_macos.rs), and can deep-link the user to the exact pane via open x-apple.systempreferences:com.apple.preference.security?Privacy_Accessibility (and the Screen Recording / Automation equivalents).

Gotchas

  • Some grants need a relaunch. Screen Recording in particular: after the user toggles it on, macOS may not honor it for the already-running process — HD's gate has a "stale" path that relaunches Hydrogen Desktop (lib.rs relaunch command) so the new grant takes effect.
  • The grant is bound to the app's code signature. An adhoc / un-notarized rebuild is seen as a "new app" and the Accessibility grant is dropped (mac_input.rs signing note). A stable Developer ID + notarization is needed for the grant to persist across builds — relevant when a dev build keeps re-prompting.
  • Graceful degradation: if Accessibility / Screen Recording are off, HD still opens the sign-in page and starts the flow — the user just approves the browser page themselves (no auto-press). It does not hard-block on these (setup_steps_macos.rs).

NOT here (lives in the Windows companion)

Windows has no per-feature OS gate equivalent to TCC — the analog is UAC (elevation for the installer / WSL2 setup), and the WebView2 PermissionRequested auto-grant handler. Screen Recording / Accessibility / Automation consent has no Windows counterpart. See hd-permissions-windows.