From Apple's new Security updates document:
App Sandbox now associates your macOS app with its sandbox container using its code signature. The operating system asks the person using your app to grant permission if it tries to access a sandbox container associated with a different app. For more information, see Accessing files from the macOS App Sandbox.
And further explanation from the document linked in the above quote:
When your sandboxed app launches for the first time, macOS creates a sandbox container on the filesystem (in
~/Library/Containers) and associates it with your app. Your app has full read and write access to its sandbox container, and can run programs located there as well.In macOS 14 and later, the operating system uses your app’s code signature to associate it with its sandbox container. If your app tries to access the sandbox container owned by another app, the system asks the person using your app whether to grant access. If the person denies access and your app is already running, then it can’t read or write the files in the other app’s sandbox container. If the person denies access while your app is launching and trying to enter the other app’s sandbox container, your app fails to launch.
The operating system also tracks the association between an app’s code signing identity and its sandbox container for helper tools, including launch agents. If a person denies permission for a launch agent to enter its sandbox container and the app fails to start,
launchdstarts the launch agent again and the operating system re-requests access.
What does this all mean, exactly? Well, I found out the hard way, by building and running a Mac app in Xcode on Sonoma.
I didn't see this the first time I ran the app, but I saw it every time I modified and re-ran the app. The reason, I discovered eventually—by remembering what I read yesterday (the above quotes)—is that the app was both sandboxed and ad hoc code signed. Ad hoc code signing is indicated by "Sign to Run Locally" in Xcode.
You'll frequently see ad hoc signing in open source Xcode projects that are distributed on the internet, because otherwise the project would depend on the developer's personal team and code signing certificates.
The arguments --sign - specify ad hoc signing with the codesign command-line tool. From the man page:
Ad-hoc signing does not use an identity at all, and identifies exactly one instance of code.
Every time I modified the app, it got a different ad hoc code signature, which is why Sonoma is complaining on subsequent launches. These cancel-or-allow style dialogs do not appear on launch for ad hoc signed apps that aren't sandboxed, because they don't have containers. However, if a non-sandboxed app attempts to access the container (~/Library/Containers/com.yourcompany.AdHocTest/Data/) of a sandboxed app, I see the following dialog:
This happens every time I run the non-sandboxed app. I don't know yet whether there's a way for a non-sandboxed app to preserve the granted file access across launches. It doesn't appear in the Files and Folders section of Privacy & Security System Settings.
Sandbox containers on Sonoma seemed to be protected in general from other apps, even from Terminal app.
Of course, Full Disk Access in System Settings overrides the restriction and grants access to everything, including sandbox containers.
A lot of what I discuss in this blog post is mentioned in the new WWDC session video What's new in privacy, starting at around the 17:30 minute mark.
I said, "I don't know yet whether there's a way for a non-sandboxed app to preserve the granted file access across launches." The answer appears to be no.