[DevEx] Local dev builds unable to test screen recording on macOS Sequoia — TCC/ScreenCaptureKit completely broken for unsigned binaries

[MinitJain]

Problem

It is currently impossible to test any screen-recording-related functionality locally on macOS Sequoia using a debug build. `CGPreflightScreenCaptureAccess()` always returns `false` for ad-hoc signed or unsigned binaries regardless of what permissions are granted in System Settings.

What was tried

1. Running the raw binary directly (`cargo build` + `./target/debug/cap-desktop`) — TCC has no bundle identity to associate the grant with, so permission is always denied.

2. Wrapping in a `.app` bundle with `codesign --sign "-"` — Signing with ad-hoc identity and a stable `CFBundleIdentifier` (`so.cap.desktop.dev`) and running via `open MyApp.app`. macOS Sequoia silently rejects ScreenCaptureKit access for ad-hoc signed apps with no Team ID. `CGPreflightScreenCaptureAccess()` still returns `false` even after granting in System Settings.

3. `tccutil reset ScreenCapture ` + fresh grant — Cleared stale TCC entries and re-triggered `CGRequestScreenCaptureAccess()`. The system dialog appeared, user approved, but on relaunch `CGPreflightScreenCaptureAccess()` still returned `false`. macOS Sequoia appears to not honor the grant for ad-hoc identities.

4. Matching bundle ID to what System Settings shows — Tried changing `CFBundleIdentifier` to `cap-desktop` to match the existing TCC entry. Same result.

5. Frameworks copy issue — `cp -R target/Frameworks` copies symlinks as real directories, causing `codesign` to fail with "unsealed contents present in root directory of embedded framework". Fixed by copying from `target/native-deps/Spacedrive.framework` which has proper relative symlinks.

Root cause

macOS Sequoia enforces that `CGPreflightScreenCaptureAccess()` / ScreenCaptureKit requires a binary signed with a valid Apple Developer ID certificate (with a Team ID). Ad-hoc signing (`codesign --sign "-"`) doesn't satisfy this requirement. This is a regression from earlier macOS versions where ad-hoc signed bundles could get TCC grants.

What currently works as a workaround

The only way to test locally is to bypass the permission check in debug builds:

```rust
OSPermission::ScreenRecording => {
#[cfg(debug_assertions)]
return OSPermissionStatus::Granted;
// real check below...
}
```

This is obviously not something that should be committed to main.

Suggested fix

Add an official `#[cfg(debug_assertions)]` bypass for `ScreenRecording` and `Accessibility` in `permissions.rs` that skips the TCC check in debug builds. This would let contributors test locally without needing a signed build. The bypass would never ship in release builds.

Alternatively, document a supported way to test dev builds (e.g. via `pnpm tauri dev` with a proper signing identity set up).

Impact

Any contributor on macOS Sequoia cannot test the permissions flow, screen recording, or any feature that requires passing the permissions screen in a debug build. This significantly raises the barrier for contributions.

[linear]

CAP-678

[tembo]

Thanks for the thorough investigation and documentation of this issue.

The permission check code lives in two places:

• apps/desktop/src-tauri/src/permissions.rs - the main Tauri command handlers
• crates/scap-screencapturekit/src/permission.rs - the underlying CGPreflightScreenCaptureAccess() / CGRequestScreenCaptureAccess() calls

The permission status logic is in macos_permission_status() at apps/desktop/src-tauri/src/permissions.rs:158-200, which calls scap_screencapturekit::has_permission().

Related issue #265 describes similar symptoms on macOS 15.2 where permission appears granted in System Settings but the app still shows it as denied - likely the same root cause you've identified with Sequoia's stricter TCC enforcement.

The codebase already uses #[cfg(debug_assertions)] conditionals extensively in the desktop app (e.g., apps/desktop/src-tauri/src/main.rs:10, apps/desktop/src-tauri/src/general_settings.rs:157) so that pattern would be consistent.

For the implementation, the cleanest approach would be modifying macos_permission_status() to return early for ScreenRecording and Accessibility when cfg!(debug_assertions) is true:

fn macos_permission_status(permission: &OSPermission, initial_check: bool) -> OSPermissionStatus {
    #[cfg(debug_assertions)]
    if matches!(permission, OSPermission::ScreenRecording | OSPermission::Accessibility) {
        return OSPermissionStatus::Granted;
    }
    
    match permission {
        // existing logic...
    }
}

This would bypass the TCC check only in debug builds and only for the permissions that require a signed binary on Sequoia. Camera/microphone can stay as-is since they prompt correctly.

PR #1479 recently refactored the permission flow, so any changes should align with the patterns introduced there (async runtime integration, proper event emission).