I realise this is very old now, but if anybody else lands here with the same question as I did without finding anything else suitable on Google .... This example is based on your app having a button labelled "+", navigating to a folder other than the default folder in the Open dialog, selecting a file you expect to exist & clicking Ok. func testAddCertificateButton() { 				let app = XCUIApplication() 				let windowsQuery = app.windows 				let addButton = windowsQuery.buttons["+"] 				XCTAssert(addButton.exists) 				addButton.click() 				let openDialog = app.dialogs.firstMatch 				XCTAssert(openDialog.waitForExistence(timeout: 5)) 				// Make sure we're on the right type of dialog by checking the "Where:" popover button exists 				// Also grab a reference to the Open button so we can click it later 				let openButton = openDialog.buttons["Open"] 				let whereButton = openDialog.popUpButtons["Where:"] 				XCTAssert(whereButton.exists) 				XCTAssert(openButton.exists) 				app.typeKey("g", modifierFlags: [.command, .shift]) 				let sheet = openDialog.sheets.firstMatch 				XCTAssert(sheet.waitForExistence(timeout: 5)) 				let goButton = openDialog.buttons["Go"] 				let input = sheet.comboBoxes.firstMatch 				XCTAssert(goButton.exists) 				XCTAssert(input.exists) 				input.typeText("/Full/Path/To/Location") 				goButton.click() 				let file = openDialog.images["FileYouExpect.txt"] 				XCTAssert(cert.waitForExistence(timeout: 5)) 				file.click() 				openButton.click() 		}

That actually should say XCTAssert(file.waitForExistence(timeout: 5)) That's what I get for modifying code in a web browser :)

We are seeing this also. When calling [OSSystemExtensionManager sharedManager] submitRequest with the result of a call to deactivationRequestForExtension for our extension, our delegate method for didFailWithError is called. I have submitted the following via Feedback Assistant ID FB9429149 When calling [OSSystemExtensionManager sharedManager] submitRequest with the result of a call to deactivationRequestForExtension for our extension, and then entering administrator credentials in the dialog which is presented to the user, our delegate method for didFailWithError is called. The code in the NSError is 4, which so far as I can tell is a OSSystemExtensionError.extensionNotFound After the failed call, if I try to run "systemextensionsctl list", I get the following output root@monterey ~ # systemextensionsctl list 3 extension(s) --- com.apple.system_extension.endpoint_security enabled active  teamID  bundleID (version)  name    [state] 2021-07-30 13:44:19.741 systemextensionsctl[698:7828] unexpectedly trying to fetch info on a non-staged bundle? zsh: abort      systemextensionsctl list But after rebooting the machine our extension is listed again and remains as [active enabled].

apologies for the formatting above, I don't understand what's happened there.

I've just tried this on Monterey Beta 5. The problem persists however the systemextensionsctl command no longer crashes, but instead still prints out our system extension in a state of [activated enabled], but now two additional lines showing the Team ID, the URI of the system extension, the version, and then "- [realizing]"

I can confirm that beta 6 also resolves the issue for us

As per the other commenters above, the principal reason for running macOS in virtualized containers is to bypass the need to dual boot a machine to get access to a beta OS for testing software, which as a workflow is cumbersome and in reality completely impractical when also needing to be joining video conferences and conforming to corporate IT security policies. Please provide us with a solution for logging in to the App Store / other iCloud services from macOS VMs on Apple Silicon.

This issue has been happening to me sporadically since Apple renewed one of the intermediary CAs involved in developer certs. At first I was fixing it by removing and regenerating certificates, it turns out the simplest way to fix the problem is to just reboot, and everything works again. Putting this here as an option for people to try before they start destroying their work environment / needlessly complicating their keychain settings where a reboot may also 'fix' things for you (at least for a couple of weeks at a time if you never shutdown/reboot otherwise).