Describe the bug
On a fresh v2.0.0-rc.1 install on macOS, while any row of the new permissions window is still pending (e.g. Accessibility, which can only be resolved in System Settings), every record press re-opens the permissions window and the take silently never starts:
- HUD record button pressed → the permissions window appears again, no countdown, no capture-helper spawn, no error message; the HUD returns to idle.
- Same from the editor's Record mode → Start recording.
- Reproduced 2/2 with Cursor highlight On.
- With Cursor highlight Off, takes start normally — so the block comes from the cursor sampler's pending accessibility requirement, but the user is given no indication of that causality.
Two problems:
- The failure is silent — the take simply does not begin; nothing says "recording is blocked until Accessibility is granted".
- The window re-opens on every press, so a user who keeps closing it (Get started) hits a loop: close → press record → window again. On a machine where the row cannot be granted with one click (Accessibility requires System Settings), recording with cursor effects is unreachable until the user happens to understand the connection.
Expected behavior
Either the take starts and cursor effects degrade gracefully, or a single clear explanation ("Recording needs Accessibility — open System Settings") is shown once, with the take starting (or a clear error) after dismissal — not an endless close/reopen loop with a silent non-start.
To Reproduce
- Fresh install of v2.0.0-rc.1 on macOS 26.5; do not grant Accessibility; close the permissions window with Get started.
- Press the HUD record button (or Record mode → Start recording) with Cursor highlight On.
- The permissions window re-appears and no recording starts. Repeat presses repeat the loop.
Environment
- Build: CI artifact
openscreen-mac-arm64, build run 36336647912, 2.0.0-rc.1 (dmg)
- OS: macOS 26.5 (25F71), Apple M1 Mac mini
- Main-process log shows no helper/recording lines during the blocked presses
Additional context
Found during the v2.0.0-rc.1 release-candidate manual pass. This blocked verifying the v2 automatic-zoom take (#822) and the hidden-cursor behavior (#731) on this machine. Related: the permissions window is documented to open "at launch, until it has been closed once, while one of its rows was never asked" — the reopen-on-record-press behavior is not documented anywhere.
Describe the bug
On a fresh v2.0.0-rc.1 install on macOS, while any row of the new permissions window is still pending (e.g. Accessibility, which can only be resolved in System Settings), every record press re-opens the permissions window and the take silently never starts:
Two problems:
Expected behavior
Either the take starts and cursor effects degrade gracefully, or a single clear explanation ("Recording needs Accessibility — open System Settings") is shown once, with the take starting (or a clear error) after dismissal — not an endless close/reopen loop with a silent non-start.
To Reproduce
Environment
openscreen-mac-arm64, build run 36336647912,2.0.0-rc.1 (dmg)Additional context
Found during the v2.0.0-rc.1 release-candidate manual pass. This blocked verifying the v2 automatic-zoom take (#822) and the hidden-cursor behavior (#731) on this machine. Related: the permissions window is documented to open "at launch, until it has been closed once, while one of its rows was never asked" — the reopen-on-record-press behavior is not documented anywhere.