Better said: a workaround I've come up with is a boot grace period during which the app and the tunnel operate (almost) unrestricted. After the grace period (2-3 minutes), I expect to validate against StoreKit with less chance of delays. It's an annoying complexity, but also one that seems to work.

What worked for me was looking for this process and killing it: /System/Library/Frameworks/StoreKit.framework/Support/storekitagent Or, just killall -9 storekitagent.

AFAIK Siri has never worked with encrypted DNS since iOS 14 introduced the feature. I can also confirm same behavior with macOS 12.6 today. Is Apple going to do anything about this? We're talking about a critical issue for VPN providers.

I was following an example invoking the inner binary via "Contents/MacOS/<binary_name>". Instead, passing the path to the *.app container to .openApplication() resolved my permission issue. Code here: https://github.com/passepartoutvpn/passepartout-apple/commit/b966826f19f5d57d0c942860b5feb7b65befee8f

+1, I'm facing the very same issue. Below is the thrown error: Error Domain=NSOSStatusErrorDomain Code=-54 "permErr: permissions error (on file open)" UserInfo={_LSLine=3845, _LSFunction=_LSOpenStuffCallLocal}}} Not sure what permission I'm omitting. Add to the weirdness: with the same method I can open "/Application/SomeApp.app" without an issue, but I can't open my main app from a bundled login item (the typical app launcher).