Unofficial archive. This is a read-only, community-run archive of the Apple Support Community. It is not affiliated with or endorsed by Apple Inc.

How do I grant access to Documents for WorkflowServiceRunner.xpc in macOS Golden Gate?

Here's my situation: M3 MacBook Air, newly upgraded to Mac OS Golden Gate. I have an Automator script which launches Terminal (which I happen to have bound to Control-Command-T, but that's irrelevant).


Right after the installation of Golden Gate I triggered my Launch Terminal Automator script and in Terminal I did "ls Documents" in that new Terminal window. This resulted in a Pop Up asking if I wanted to grant WorkflowServiceRunner.xpc access to Documents and I was so surprised by this that I stupidly answered "no".


Now that decision has been recorded forever and I can't find where it's recorded to fix this problem. (sigh) Can anyone point me to what shell commands I should us for this since System Settings -> Privacy & Security isn't helpful in any fashion, not does the Finder Get Info help in any way.


And note that creating a new Terminal Window or even a new Terminal Tab will immediately allow me to access Documents ... so this broken security issue only affects the initial Window and shell, nothing else. But I guess this can be explained by these new shells as not being "WorkflowServiceRunner.xpc" (double sigh)


There are of course many bugs in this scenario:

  1. It never should have been "WorkflowServiceRunner.xpc" which was listed as needing permission; it should have been Terminal.
  2. If we are going to have per-application restrictions/permissions being recorded via Pop Up Windows, those should be visible and changeable via some interface ...
  3. The initial Terminal Window/Shell should not have a different "Application Identity" from all subsequent Windows/Shells.


[Re-Titled by Moderator]

Original Title: Mac OS Golden Gate Automator launched Terminal asks via Pop Up if "WorkflowServiceRunner.xpc" should be granted access to Folder and the resulting response is hidden and can't be changed


4 replies

The standard Apple Genius Bar folks closed down my ticket saying that this was more of a "Developer Thing" since normal users don't use Automator Scripts. I could argue, but yeah, we're fairly deep in the woods and I already knew we were headed into talking to OS Developers (I'm one myself and used to work for Apple). I've been meaning to pick this issue up again on my Developer Account but have gotten distracted by a bunch of things. I'll try to pop a note out today, and if not today, this weekend for sure. I'll update this ticket here with anything I learn.


By the way, my latest thoughts on this are:

  1. Again, somewhere buried deep in the first Terminal Instance invoked by the Automator Script's WorkflowServiceRunner.xpc is that identity rather than my own User ID ... but the Terminal application's own Forked Instances (Command-N, Command-T) don't copy that and instead those Forked Terminal Instances are 100% my User ID ... so it feels like the WorkflowServiceRunner.xpc may only be associated with the first Terminal Instance TTY Group ... Regardless, of the mechanism of how this is happening, this actually points to a Security Bug since the forking of the new Terminal Instances loses the Security Identity of the original invoker ...
  2. It feels like the Security Check is being performed based on traveling through an iCloud Mount Point. So this may be the next place I look while waiting for answers from my Developer Account ...

Ah ha! The first real difference I've found between the initial Terminal instance launched by the Automator Script and a subsequent Terminal instance created via either Command-N or Command-T. In the Automator launched Terminal instance I have:

leedom@margulis:~ ls -ld@ Documents
drwxr-xr-x@ 54 leedom  staff  1728 Oct  5 16:17 Documents/
	com.apple.file-provider-domain-id	  80 
	com.apple.fileprovider.detached#B	  -1 
	com.apple.icloud.desktop	   8 
leedom@margulis:~ 


And in a Command-N Terminal instance I have:

leedom@margulis:~ ls -ld@ Documents
drwxr-xr-x@ 54 leedom  staff  1728 Oct  5 16:17 Documents/
	com.apple.file-provider-domain-id	  80 
	com.apple.fileprovider.detached#B	 877 
	com.apple.icloud.desktop	   8 
leedom@margulis:~ 


Steps tried so far:

  1. I've tried using mdls and xattr on ~/Documents to see if I can find any residual meta data covering WorkflowServiceRunner.xpc and its lack of permissions to access Documents. I'compared the output of mdls and xattr on ~/Dowloads and can't see WorkflowServiceRunner.xpc there either.
  2. I've tried to see if there's any difference in the process execution environment between the first Terminal window shell and that of a second Terminal window. I assume that there's some Mac OS system call which can distinguish them, but none of the usual commands seems to show it. The parent processes all the way back to init (Process ID 1) look identical.
  3. I've added both Terminal and WorkflowServiceRunner.xpc to Settings -> Privacy & Security -> Files & Folders, with Full Disk Access.
  4. I've added both Terminal and WorkflowServiceRunner.xpc to Settings -> Privacy & Security -> Full Disk Access.
  5. I've reinstalled Mac OS Golden Gate (without wiping the disk).


So far, no luck.

I'm having the same issue-- I too didn't give access initially to my downloads folder, and now my quick actions don't work. When prompted I gave access to the desktop folder, and they work fine there. Have been unable to figure out a fix for this. This is extremely frustrating-- you should be re-prompted about this instead of only having one chance to answer.