{"id":48377,"date":"2025-07-07T14:58:22","date_gmt":"2025-07-07T18:58:22","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=48377"},"modified":"2025-07-07T14:58:22","modified_gmt":"2025-07-07T18:58:22","slug":"the-curious-case-of-the-responsible-process","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/07\/07\/the-curious-case-of-the-responsible-process\/","title":{"rendered":"The Curious Case of the Responsible Process"},"content":{"rendered":"

Tor Arne Vestbø<\/a>:<\/p>\n

As it turns out, permissions are inherited by child processes. And when a process is about to access some protected resource, the TCC subsystem figure’s out which process is the responsible<\/em> one, and uses that as basis for requesting and persisting the result.<\/p>

[…]<\/p>

In the case of an application embedding and launching helper executables this behavior of course makes sense, but it can be a bit surprising in cases such as launching apps from the terminal.<\/p>

[…]<\/p>

As it turned out, since Qt Creator was launching user<\/em> applications when running and debugging, it was effectively becoming the responsible process for all these user applications. And if one of them required a permission that needed a corresponding usage description, then the only way to make the application work was to add the description to the responsible process; Qt Creator.<\/p>

[…]<\/p>

Somehow lldb<\/code> was circumventing the logic that was deciding which process was the responsible one.<\/p>

Luckily LLDB is part of the open source LLVM project, so I was able to track it down to this<\/a> change, with the magic formula:<\/p>

int responsibility_spawnattrs_setdisclaim(posix_spawnattr_t attrs, int disclaim);<\/code><\/p><\/blockquote>\n\n

He says it “just works” with Xcode, though he isn’t sure why, but my experience is that often neither Xcode nor the app prompts for Automation or Contacts access when running an app or testing and so the APIs just fail.<\/p>\n\n

Via Peter Steinberger<\/a> (tweet<\/a>):<\/p>\n

\n

If you’re building a macOS CLI that uses AppleScript, you need to embed an Info.plist into your binary, sign it with proper entitlements, and optionally use the undocumented responsibility_spawnattrs_setdisclaim<\/code> API to avoid permission dialogs that blames the hosting app.<\/p>\n

[…]<\/p>\n

Getting AppleScript to work in a CLI tool turned out to be a maze of undocumented APIs, security permissions, and macOS quirks that nobody warns you about.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n