Mail destination: Cai missing from macOS Automation permissions because release build lacks Apple Events entitlement

[rafjaf]

Description

The built-in Mail output destination does not work with the official Cai 1.5.3 release.

When trying to send a result to Mail, Cai displays:

Cai requires Automation access to Mail to draft an email from Cai results.
Go to System Settings → Privacy & Security → Automation and enable Mail under Cai.

However, Cai does not appear at all under System Settings → Privacy & Security → Automation, so there is no way to enable Mail manually.

Resetting TCC/Apple Events permissions does not solve the problem.

Version

Cai 1.5.3 (com.soyasis.cai)

Official release DMG:

Cai-1.5.3-macos.dmg

SHA-256:

6812c5918f89ed84d108a791194eb52045f5d41c87b33120822873983f9ac593

The same issue occurs when inspecting/running the copy directly from the official DMG, so it does not appear to be caused by local modification of the installed app.

Investigation

The bundle identifier is correct:

/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' /Applications/Cai.app/Contents/Info.plist

returns:

com.soyasis.cai

Likewise:

osascript -e 'id of application "Cai"'

returns:

com.soyasis.cai

and the code signature reports:

Identifier=com.soyasis.cai
CodeDirectory v=20500 ... flags=0x10000(runtime) ...
TeamIdentifier=T666G8244

So the release is using Hardened Runtime.

However, inspecting the signed entitlements:

codesign -d --entitlements - /Applications/Cai.app

only outputs:

Executable=/Applications/Cai.app/Contents/MacOS/Cai

with no entitlement plist.

This is unexpected because the v1.5.3 source contains:

<key>com.apple.security.automation.apple-events</key>
<true/>

in Cai/Cai/Cai.entitlements, and the Release Xcode configuration contains:

CODE_SIGN_ENTITLEMENTS = Cai/Cai.entitlements;

The v1.5.3 Info.plist also correctly contains NSAppleEventsUsageDescription.

This suggests that the entitlement is being lost during the build/signing/distribution process for the official release.

Because the distributed binary has Hardened Runtime enabled but lacks:

com.apple.security.automation.apple-events

macOS apparently cannot present the normal “Cai wants to control Mail” authorization dialog. Consequently no Cai → Mail entry is created in Privacy & Security → Automation.

Reproduction

1. Install Cai 1.5.3 from the official DMG.
2. Configure/use the built-in Mail destination.
3. Attempt to send a Cai result to Mail.
4. Cai reports that Automation permission must be enabled.
5. Open System Settings → Privacy & Security → Automation.

Actual: Cai is not listed.

Expected: macOS should prompt for Cai to control Mail, after which Cai → Mail should appear in Automation.

Resetting the permission does not help:

tccutil reset AppleEvents com.soyasis.cai

Temporary workaround

I was able to make the Mail destination work by locally re-signing Cai with the missing Apple Events entitlement.

Because an ad-hoc re-sign changes the signing identity of the main executable while Cai contains embedded frameworks signed with the original developer identity, simply adding the Apple Events entitlement caused Cai to stop launching.

The working temporary fix was therefore to add both:

<key>com.apple.security.automation.apple-events</key>
<true/>

<key>com.apple.security.cs.disable-library-validation</key>
<true/>

Create /tmp/Cai.entitlements:

cat > /tmp/Cai.entitlements <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.automation.apple-events</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
</dict>
</plist>
EOF

Then re-sign the main app:

codesign --force \
  --sign - \
  --options runtime \
  --entitlements /tmp/Cai.entitlements \
  /Applications/Cai.app

Afterwards:

codesign -d --entitlements - /Applications/Cai.app

correctly shows both entitlements.

Finally reset Apple Events authorization:

tccutil reset AppleEvents com.soyasis.cai

and launch Cai again.

After doing this, Cai successfully triggered the macOS Automation permission flow and the Mail destination started working.

Caveat about the workaround

This is obviously only a local workaround:

• it replaces the developer's original signature with an ad-hoc signature;
• disable-library-validation is needed only because of that local re-signing situation;
• a future Cai update will presumably overwrite the modified application;
• the proper fix should be for the official Cai release to retain com.apple.security.automation.apple-events in its Developer ID-signed binary.

It would probably also be useful for the release process to verify the final artifact with something like:

codesign -d --entitlements - Cai.app

before packaging/publishing the DMG.

Disclaimer

Bug report written with the help of ChatGPT

[soyasis]

Thanks for the detailed write-up @rafjaf, your diagnosis was spot on!
Root cause confirmed: the release re-sign ran codesign --force ... --sign with no --entitlements, which strips the entitlements the archive embedded, so the shipped build had Hardened Runtime but no com.apple.security.automation.apple-events, breaking the Mail Automation prompt....

Fixed by re-applying --entitlements on the resign, plus a pre-ship check (codesign -d --entitlements -) so this can't slip through again. Ships in the next release. Thanks again!

[rafjaf]

Thank you @soyasis for your swift reply and action !