Thanks Quinn, I appreciate you. This additional context helps. I currently don't intend to ship via Mac App Store but would like to distribute releases with an installer (.dmg or .pkg) which now appears to require notarization. I'd appreciate clarifications for the temporary exceptions for Enterprise deployments. Leveraging TestFlight so that I can get feedback and crash reports in Xcode would also be appreciated. There are actually 2 dot folders I'd need to access. One is ~/.ssh because we are using the RSA certificate auth feature in OpenSSH to connect to a system. That auth tool creates a file at ~/.ssh/ id_rsa-cert.pub which is needed to make SSH/SCP connections. Our tooling which authenticates user sessions generates this certificate file with a limited lifetime along with files in another dot folder which I would need to interact with internal services. For both I think the right architecture and security recommendation would be to store these assets in the keychain using an access group. I can make a request to do this, but it may not be a high enough priority to be considered. I've read up on XPC services, daemon processes and user agents on macOS but I did not see any details about the App Sandbox and Hardened Runtime policies. Could you also request clarification related to these use cases?

I found the answer. I can use the entitlement below despite that it is named a temporary exception. This has been in place for years and appears to be allowed all this time. I can add /.ssh/ to the list under this value to access the config and keys. There are other folders I will need to access which will work this way. com.apple.security.temporary-exception.files.home-relative-path.read-write

Another option I am considering is having the certificate which is stored in this file copied into a keychain item which could be accessed with a keychain access group. Then Mac apps can access it and monitor it for changes.

I get the same errors. Also tried python3.9 and it still fails.

I came across this question because I was running instances of Process and connecting Pipe to the FileHandle and found it was using an excessive amount of CPU due to many calls to the handleInput function. The readabilityHandler property is set to this function to handle the data. What I found is that I needed to call waitForDataInBackgroundAndNotify which prevented the handler functions from being called frequently with no data. With your process make sure you call launch and waitUntilExit so that your function does not finish early. And if you are running a Command Line Tool you may want to add a call to dispatchMain() to prevent the process from terminating until the code calls exit. let outPipe = Pipe() let errPipe = Pipe() task.standardOutput = outPipe task.standardError = errPipe outPipe.fileHandleForReading.readabilityHandler = handleInput(fileHandle:) errPipe.fileHandleForReading.readabilityHandler = handleError(fileHandle:) outPipe.fileHandleForReading.waitForDataInBackgroundAndNotify() errPipe.fileHandleForReading.waitForDataInBackgroundAndNotify()

I got the answer from a co-worker. It was a setting which I did not change myself but I was able to change it back. Under the menu: Debug > Debug Workflow check Always Show Disassembly to make sure it is not checked. This fixes the problem.