Hello, The "Removable Volume access request" is actually triggered by a start() call to ICDeviceBrowser (this class can scan for cameras and scanners connected to the computer) The flow is like this: I. In the main app discovers the connected scanners or cameras like this: let browser: ICDeviceBrowser browser.start() // This will trigger the Removable Volume access request II. I accept the request and devices are discovered and connected. III. After a device is discovered I create a new FileProvider extension for the new connected device. IV. In the FileProvider class I connect to the scanner, but to connect to a scanner I must start again a device browser monitor in order to have a reference to the actual scanner device: let browser: ICDeviceBrowser browser.start() start() will trigger the Removable Volume access request, this time inside the FileProvider. This is where it fails, see above the error message. I don't know why it triggers again the request, the main app is already confirmed. This workflow worked fine until now (before macOS Sequoia). Thank you.

If the user gives access to Bluetooth to the main app, does the containing daemon or system extension inherit the permission?

Actually this does not happen only in Finder, but also in terminal if you list a path (ls path).

Hello, Unfortunately, with the new iOS 17 this problem is stil persistent.

Hello, Unfortunately, with the new iOS 17 this problem is stil persistent.

Hello, Unfortunately, with the new iOS 17 and XCode 15 Beta this new feature is not supported.

Yes, for sure, there are a lot of apps on the App Store can use ScreenCaputreKit.

Hello, Any updates on this issue? Any new option added in the new macOS Ventura to copy instead of move a dragged file? Thank you.

Intel Iris Plus Graphics 655 1536 MB, sorry, not AMD Radeon.