ID: 20260923155300

Yes — that error is almost certainly macOS privacy/TCC protection, not a find problem. ~/Library/Mail is one of the specially protected locations.

On macOS 27, the important detail is which process actually executes find. In an AppleScript/Automator workflow, granting Terminal Full Disk Access may do nothing because Terminal isn’t the process touching the Mail directory.

For example, if your workflow contains:

do shell script "find " & quoted form of "<obscured path>/" & " -type f"

then macOS may attribute the access to an AppleScript/Automator runner rather than /usr/bin/find.

First, isolate the problem

Run this directly in Terminal:

find ~/<obscured path>/ -maxdepth 1 -print

There are two useful outcomes:

If Terminal also says Operation not permitted: give Terminal Full Disk Access in:

System Settings → Privacy & Security → Full Disk Access

Then completely quit Terminal and reopen it.

If Terminal works, but the AppleScript workflow fails: that’s the more interesting case, and probably what you’re encountering on macOS 27. The workflow’s execution host needs permission.

If this is an Automator workflow

Check System Settings → Privacy & Security → Full Disk Access for things such as:

• Automator
• the application from which you’re launching the workflow
• an application you’ve created/exported from Automator

The awkward part is that Automator workflows can be executed by helper processes such as com.apple.AutomatorRunner, depending on how the workflow is invoked. This has historically made TCC permissions for Automator workflows rather messy.

One particularly useful test is to create a tiny AppleScript application:

do shell script "/usr/bin/find " & ¬
	quoted form of "<obscured path>" & ¬
	" -maxdepth 1 -print"

Save it from Script Editor as an Application, then add that application explicitly to:

Privacy & Security → Full Disk Access

Quit/relaunch it and test.

If that works while your Automator workflow doesn’t, we’ve established that macOS 27 has changed which execution context/TCC identity is being used, rather than there being anything wrong with find.

One other thing catches my eye

You’re explicitly addressing:

~/Library/Mail/V10/

macOS Mail’s internal storage version changes between OS releases. Before changing anything, run:

ls -ld ~/Library/Mail/V*

If macOS 27 has migrated Mail to another Vxx directory, we should modify your workflow so that it doesn’t hard-code V10 at all.

Since you say this exact workflow worked under macOS 26 and stopped under macOS 27, I’d troubleshoot it in this order:

# 1. Does Terminal have access?
find ~/<obscured path>/ -maxdepth 1 -print

# 2. What Mail versions actually exist?
ls -la ~/Library/Mail/

# 3. Check the particular directory
ls -ld ~/<obscured path>/

If #1 works in Terminal but the AppleScript gives Operation not permitted, send me the portion of your AppleScript/Automator workflow that calls find and tell me how the workflow is launched (Automator Quick Action, Folder Action, Mail rule, standalone app, etc.). That distinction is crucial here; we can then identify the macOS 27 process that actually needs the permission.

ID: 20260923155400

Excellent — that pretty much nails down the execution chain.

Your Service is being hosted by:

WorkflowServiceRunner
    ↓
com.apple.automator.runner
    ↓
sh
    ↓
find
    ↓
~/Library/Mail/...

And PID 46783 confirms the important part:

46774  com.apple.automator.runner
  │
  └── 46783  sh -c ...

So com.apple.automator.runner is the process actually spawning your shell script. This also explains why giving Automator.app Full Disk Access doesn’t solve Services run outside Automator.

First thing I’d try

Add this executable to System Settings → Privacy & Security → Full Disk Access:

/System/Library/Frameworks/Automator.framework/Versions/A/XPCServices/com.apple.automator.runner.xpc/Contents/MacOS/com.apple.automator.runner

The problem is that the Full Disk Access GUI normally wants you to select an application bundle rather than an executable buried inside an XPC bundle.

Try adding the XPC bundle itself:

/System/Library/Frameworks/Automator.framework/Versions/A/XPCServices/com.apple.automator.runner.xpc

In Finder you can reach it with Go → Go to Folder… and paste:

/System/Library/Frameworks/Automator.framework/Versions/A/XPCServices/

Then try dragging:

com.apple.automator.runner.xpc

into the Full Disk Access list.

Afterwards, I’d kill all existing instances:

killall com.apple.automator.runner
killall WorkflowServiceRunner

They’ll automatically be recreated when needed.

Then run your old Service again.

There’s another candidate

Your process listing also shows:

/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/WorkflowServiceRunner.xpc/Contents/MacOS/WorkflowServiceRunner

That’s likely the outer host for macOS Services.

So if granting FDA to com.apple.automator.runner.xpc alone doesn’t work, I’d also try:

/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/WorkflowServiceRunner.xpc

The distinction matters because Apple’s TCC system can make authorization decisions based on the responsible process, not simply the Unix process that ultimately performs the filesystem operation.

We can determine which one TCC is actually rejecting

Rather than guessing, macOS’s privacy log should tell us.

Open a Terminal and run:

log stream --style compact \
  --predicate 'subsystem == "com.apple.TCC"' \
  --info

Then trigger one of your broken Services.

We’re looking for a line containing things such as:

kTCCServiceSystemPolicyAllFiles

or:

SystemPolicyAllFiles

and, particularly, identifiers resembling:

com.apple.automator.runner

or:

WorkflowServiceRunner

You can make the output less noisy with:

log stream --style compact \
  --predicate 'subsystem == "com.apple.TCC" AND (eventMessage CONTAINS[c] "automator" OR eventMessage CONTAINS[c] "WorkflowService")'

Trigger the failing Service while that is running.

Why I think this is worth pursuing

Your experiment gives us a very clean A/B comparison:

Run inside Automator
        ↓
Automator.app
        ↓
Mail access ✓

Run as Service
        ↓
WorkflowServiceRunner
        ↓
com.apple.automator.runner
        ↓
Mail access ✗

Standalone .app
        ↓
Mail access ✗

Standalone .app + FDA
        ↓
Mail access ✓

That’s strong evidence that macOS 27 changed/enforced the TCC boundary for these workflows.

And if TCC lets us authorize either WorkflowServiceRunner or com.apple.automator.runner, that’s by far the best outcome for you: one Full Disk Access authorization could potentially restore your whole collection of old Automator Services without touching their code.

I’d try adding com.apple.automator.runner.xpc first. If macOS 27 refuses to let you add it, or adding it doesn’t solve the problem, run the TCC log stream test and paste the few lines generated when you invoke the Service. That should tell us exactly which executable/signing identity macOS 27 is denying.

ID: 20260924040700

Yes — this log gives us the answer, and it also corrects one part of my previous suggestion.

The critical lines are these:

responsible={
  identifier=com.apple.automator.xpc.workflowServiceRunner
  ...
  responsible_path=.../WorkflowServiceRunner
}

requesting={
  identifier=com.apple.automator.xpc.runner
  ...
}

and then, decisively:

AUTHREQ_SUBJECT:
subject=com.apple.automator.xpc.workflowServiceRunner

Pasted text

So TCC is treating WorkflowServiceRunner, not com.apple.automator.runner, as the security identity responsible for your Service.

The macOS 27 problem is even clearer

TCC then tries to resolve that identity:

Failed to create LSApplicationRecord for
.../WorkflowServiceRunner.xpc/

OSStatus error -10811

Pasted text

And separately it can’t properly resolve the inner Automator runner either:

Unable to find this application extension record
in the Launch Services database.

Pasted text

That is quite interesting. This looks less like your old workflows being incompatible and more like macOS 27’s TCC/LaunchServices handling of Automator Services has changed or is broken.

Most importantly, Mail itself tells TCC exactly which executable it considers responsible:

kTCCCodeIdentityExecutableURL =
".../WorkflowServiceRunner.xpc/Contents/MacOS/WorkflowServiceRunner"

kTCCCodeIdentityIdentifier =
"com.apple.automator.xpc.workflowServiceRunner"

Pasted text

Therefore, try FDA on WorkflowServiceRunner

Forget com.apple.automator.runner for the moment. The thing we want to authorize is:

/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/WorkflowServiceRunner.xpc

Try dragging that XPC bundle into:

System Settings → Privacy & Security → Full Disk Access

Use Finder → Go → Go to Folder…:

/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/

and find:

WorkflowServiceRunner.xpc

Try dragging it directly onto the FDA list.

If System Settings accepts it, enable it.

Then kill the existing runners:

killall WorkflowServiceRunner 2>/dev/null
killall com.apple.automator.runner 2>/dev/null

and invoke your old Service again.

But I suspect macOS may refuse it

The significant clue is:

Failed to create LSApplicationRecord

That suggests macOS 27 doesn’t regard this XPC bundle as an ordinary application that System Settings can manage through the normal FDA UI.

If dragging the .xpc into Full Disk Access doesn’t work, don’t spend time trying random executables. We have enough evidence now to investigate the macOS 27-specific TCC situation directly.

In particular, I would next determine whether there’s a supported way to give

com.apple.automator.xpc.workflowServiceRunner

SystemPolicyAllFiles authorization, or whether this is a macOS 27 Automator regression.

Your log is unusually good evidence because it establishes the whole chain:

Automator Service
       ↓
WorkflowServiceRunner
com.apple.automator.xpc.workflowServiceRunner
       ↓
        TCC
       ↓
RESPONSIBLE / SUBJECT
       ↓
com.apple.automator.xpc.runner
       ↓
shell/find
       ↓
~/Library/Mail
       ✗

And that’s why Run in Automator works while Run as Service doesn’t.

Try dragging WorkflowServiceRunner.xpc into Full Disk Access. Tell me exactly what happens — accepted and appears in the list / rejected / nothing happens / appears but still doesn’t work. The next step differs substantially depending on which of those happens.