Skip to content

fix: trigger the real macOS Screen Recording prompt instead of bouncing to Settings - #12

Merged
Alfredoalv13 merged 1 commit into
mainfrom
fix/trigger-screen-recording-prompt
Jul 24, 2026
Merged

fix: trigger the real macOS Screen Recording prompt instead of bouncing to Settings#12
Alfredoalv13 merged 1 commit into
mainfrom
fix/trigger-screen-recording-prompt

Conversation

@Alfredoalv13

Copy link
Copy Markdown
Owner

Summary

  • macOS has no programmatic "request" API for Screen Recording permission (unlike camera/microphone) - the only thing that triggers the real system dialog is an actual capture-related call. `getMediaAccessStatus()` is a passive status read.
  • `startStudioRecording` checked that status and, when not granted, jumped straight to `openScreenRecordingPreferences()` (System Settings) - so if the app had never actually been through the real prompt, there was nothing there for a user to grant, and clicking Record could never trigger it.
  • Verified directly this session: repeatedly clicking Record opened System Settings with zero native permission dialogs ever appearing, for a bundle that had never been prompted or denied.
  • Fix: when permission isn't granted, call `getSources()` first (a lightweight call the source selector needs anyway, and exactly what triggers the real OS prompt), then re-check status. Only fall back to the Settings redirect if it's still not granted after that attempt.

Test plan

  • `tsc --noEmit` clean
  • `npm test` - 94/94 files, 818/818 tests passing (added a test covering the not-determined -> prompt -> granted path)
  • Manual: on a machine where VybeClip has never been granted or denied Screen Recording, click Record and confirm the real macOS "Allow VybeClip to record this computer's screen?" dialog now appears

…g up

macOS has no API to programmatically request Screen Recording access (unlike
camera/microphone's askForMediaAccess) - the only thing that ever shows the
real system permission dialog is an actual capture-related call. getMediaAccessStatus()
is a passive read of already-decided state.

startStudioRecording checked that status and, if not granted, jumped straight
to opening System Settings - so a user who had never been prompted before had
nothing to grant there, and could never actually trigger the real dialog
through normal use of the Record button. Verified this directly this session:
clicking Record repeatedly opened System Settings with no native dialog ever
appearing, for an app that had genuinely never been granted or denied.

Now, when permission isn't granted, we call getSources() (which the source
selector already needs anyway) to trigger the real prompt first, then
re-check. If the user was already explicitly denied before, this just fails
silently same as before and we still fall back to Settings.
@Alfredoalv13
Alfredoalv13 merged commit 1abc5c9 into main Jul 24, 2026
1 check passed
@Alfredoalv13
Alfredoalv13 deleted the fix/trigger-screen-recording-prompt branch July 24, 2026 17:39
Alfredoalv13 pushed a commit that referenced this pull request Jul 24, 2026
Same root cause as the Screen Recording fix (#12), for Accessibility:
getAccessibilityPermissionStatus() calls isTrustedAccessibilityClient(false),
a passive read that never prompts or registers the app in System Settings.
requestAccessibilityPermission() (isTrustedAccessibilityClient(true)) already
existed in the backend and is exposed to the renderer, but was never called
anywhere - startStudioRecording jumped straight to opening System Settings
when accessibility wasn't trusted, leaving nothing there to grant on first use.

Verified directly this session: after fixing Screen Recording, an otherwise
fresh app install kept showing "Accessibility permission is required" even
after toggling what appeared to be the correct entry in System Settings and
doing a full quit-and-reopen, because that request path was never exercised.

Now mirrors the Screen Recording fix: call requestAccessibilityPermission()
when not yet trusted, then re-check, before falling back to Settings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants