Thanks Quinn — your explanation of the framework-linkage trick was exactly the pointer we needed. To answer your question first: no, ShazamKit didn't appear in otool -L on that executable — it's an Xcode Debug build, so the executable only imports the debug-dylib stub, and ShazamKit is imported one hop down by that dylib. That prompted two more controls, and they solved it: Rebuilding the helper with a direct static ShazamKit import (confirmed via otool -L) and spawning it as an inherit child: still error 202, same shazamd deny. The child's own linkage doesn't matter. Linking ShazamKit into the parent executable instead (a tiny sandboxed fork/exec launcher, no exception anywhere): the unmodified inherit child now matches — including through two levels of nesting. So the sandbox extension appears to be derived from the profile owner's linkage and flows down to inherit children. That explains my app exactly: my main executable never linked ShazamKit (only the spawned helper does), hence the denial, hence the temporary-exception having been load-bearing. My path forward is clear — link ShazamKit in the main app and drop the temporary-exception. Thanks for steering me to the mechanism; I wouldn't have found it without that hint. One last thing, purely for completeness: if "a child's own static import doesn't extend an inherited sandbox" is something you'd consider a gap rather than intended behaviour, say the word and I'll file Feedback with the reproduction — otherwise I'm all set.

Thanks for the reply, Quinn — and good instinct: the helper turns out to be exactly the factor. I ran a set of controls to answer your question, and I have to correct my original post in the process. Same machine (macOS 26.1 / 25B78), same binary, same Apple Development signing: When the sandboxed app calls SHSession.match directly (entitlements: just com.apple.security.app-sandbox + com.apple.security.network.client — no exception, no ShazamKit-related entitlement at all), it matches successfully. No shazamd denial. So point 1 of my original post was wrong: a directly-sandboxed process can reach com.apple.shazamd out of the box. The same binary signed app-sandbox + com.apple.security.inherit and spawned as a child of that same sandboxed parent (parent has no exception) fails with error 202 ("connection to com.apple.shazamd was invalidated"). Same result one level deeper (parent → inherit child → inherit grandchild, which is my production shape). The same nested chain with com.apple.security.temporary-exception.mach-lookup.global-name = [com.apple.shazamd] on the parent matches fine. So: ShazamKit works under the sandbox in the main process with no special entitlements, but a com.apple.security.inherit child loses access to com.apple.shazamd unless the parent carries the temporary-exception. What should I do here? Is this expected behaviour for inherit children — and if so, is the parent-level temporary-exception the supported way to use ShazamKit from a spawned helper (my architecture needs the match to run in one)? Or is this a gap in how the ShazamKit allowance is granted, in which case I'm happy to file a Feedback with the reproduction (it's a ~40-line fork/exec launcher plus the entitlement plists) and keep using the exception in the meantime — whichever you advise.