Replies: 1 comment
|
On Windows this does not look like a missing system screen-recording setting. The macOS screen-capture permission prompt is macOS-specific; Windows should normally rely on the app/Electron permission flow. Your second screenshot is probably the useful clue. Looking at the current AIRI source, the Electron permission handler explicitly allows local The vision screen-capture code then starts the stream with: navigator.mediaDevices.getDisplayMedia({ video: true, audio: false })So if Electron/Chromium reports the Windows picker as a I would treat this as an AIRI permission-policy bug, not as a Windows setting you missed. The useful report would be:
A likely fix is for AIRI to explicitly allow the local app screen-capture path on Windows/Electron, or to adjust the permission handler so this vision capture request is not rejected as camera/video media. Trying random Windows privacy settings probably will not help unless AIRI changes that app-level permission decision. If this points to the right cause, please mark it as answered so Windows vision users can find the permission-policy explanation. |


On Windows this does not look like a missing system screen-recording setting. The macOS screen-capture permission prompt is macOS-specific; Windows should normally rely on the app/Electron permission flow.
Your second screenshot is probably the useful clue. Looking at the current AIRI source, the Electron permission handler explicitly allows local
display-capture, but it only allowsmediapermissions when they are audio-only. The tests also intentionally rejectmediaTypes: ["video"]andmediaTypes: ["audio", "video"].The vision screen-capture code then starts the stream with:
So if Electron/Chromium reports the Windows…