From a user's or developer's perspective this behavior is not comprehensible. If I build a command line tool in Xcode and it lacks FDA approval, it doesn't work ✅ If I then add FDA for that binary and run it from Xcode it works ✅ but then it still can't be run from the terminal (if the terminal does not have FDA), what? 🚨 **Why is the FDA approval only honored when it is run by Xcode? ** How can I compile a program w/o Xcode and grant it FDA? The fact that this kind of behavior is not clearly documented (and all the other missing important documentation) is a constant source of frustration for us developers.

Thanks, that's helpful. Each of these has a fairly well-understood TCC story, and I’m happy to go into those details. That would be much appreciated! I initially encountered this problem when trying to use CLion by Jetbrains. When I try to develop a command line tool in CLion and run it there, my program does not get FDA unless I approve FDA for CLion - my actual program does not matter. While this seems to go against the least privilege approach, I can live with that. What would Jetbrains need to do to behave like Xcode in this case? Would the story differ if I put the command line tool in an app bundle?

Thanks for your help Quinn. I figured out what the problem was. As documented, exec events increase the pidversion. But what's not documented is that even attempted execs are also increasing the pidversion. So if another ES client is denying an exec, this still increases the pidversion for that process. Accounting for this edge case, I was able to fix the traceability chain.

Thanks for your help Quinn, as always. Yes, we definitively fall under the second category. We were under the impression that daemons and agents must live under /Library/LaunchDaemons starting with Ventura and that this will become mandatory some time in the future. The documentation said: In apps that target macOS 13 and later, your app needs to only use the property list locations outlined above. If we can continue to put our launchd plists under /Library/Launch... and ignore SMAppService that would be great. I was following the provided example Xcode project in which an installer package is created and then calls the SMAppService part during the postinstall. I just assumed that "this is the way", even if it is very painful.

I'm facing the same problem. Were you able to fix it?

Thank you both for your help @Shay39 @DTS Engineer Quinn ! It really was the wrong address. I just tested it again with interface addresses other than loopback and it works just fine. It also works with the firewall enabled. I already tested other interface addresses, but when I did there were probably other things wrong and I discarded the idea. @Quinn: Thanks for the reply on the other thread, I didn't get a notification. Thanks again!

Thanks, that works. However, this records traces for all processes. Is there a way to limit the recording to a particular process? That's a benefit with ktrace. I couldn't find this in the man page of trace.

Thanks Quinn, that matches my understanding. Sadly, I didn't find that article during my research, would have saved me a lot of work. Is there an overview of your articles somewhere? It's quite hard to find them.

Thanks a lot!