Not Authorized to Send Apple Events: I Got -609 Instead

The error string everyone documents is Not authorized to send Apple events to System Events. (-1743). I went looking for it on my own machine today and could not produce it once. What my headless Mac mini actually does, when an unattended job sends an Apple event, is sit in mach_msg for 66 seconds and then return -609, a completely different error with a completely different meaning. Eight of my first twenty-eight probes looked like permanent hangs. They were not hangs, and finding that out corrected my own first conclusion.

This matters because a blocked Apple event inside a scheduled job is worse than a denied one. A denial returns in milliseconds and you can branch on it. A 66-second block in a slot that runs every 90 minutes eats your schedule, and the error you finally get does not mention permissions at all.

The rig, and why headless does not mean sessionless

Mac16,10, M4, macOS 26.4.1 build 25E253, arm64, SIP enabled, FileVault on, 27 days uptime, no monitor attached. I run agent jobs here over SSH and launchd. The first thing worth establishing is that this machine does have a GUI session, because almost every answer about Apple events assumes the opposite:

$ launchctl managername
Aqua
$ launchctl print gui/$(id -u) | head -3
gui/501 = {
	type = login
$ stat -f '%Su' /dev/console
sg-mini
$ tty
not a tty

So there is a logged-in Aqua session owned by my user, and my shell is not a terminal. The window server is up. There is simply nobody in front of it. That distinction is the whole story.

The probe matrix

macOS ships no timeout(1), which I measured the hard way a while back, and a consent path can block indefinitely, so every probe ran in its own process group with a hard kill:

p = subprocess.Popen(argv, stdout=PIPE, stderr=PIPE, start_new_session=True)
try:
    out, err = p.communicate(timeout=20)
except subprocess.TimeoutExpired:
    os.killpg(os.getpgid(p.pid), signal.SIGKILL)   # group, not pid

Twenty-eight probes, 20-second cap, all from the unattended shell:

Group	Probes	Result
Self-contained AppleScript	literal, 2+2, current date, do shell script, path to home folder, system attribute, two JXA	8 of 8 returned, 0.02 to 0.06s
UI calls in-process	display notification 0.06s, display dialog 2.28s, display alert 2.3s, beep 0.51s	4 returned; choose file hit the cap
Apple events to System Events	current user, process count, UI elements enabled, process list, frontmost app	0 of 5 returned
Apple events to other apps	Finder startup disk, Finder home	0 of 2 returned
Session-dependent CLI	pbcopy to pbpaste round trip works; launchctl managername; TCC.db read denied	screencapture -x fails: could not create image from display

Two lines there are useful on their own. The clipboard works without a human, so pbcopy is safe in a scheduled job, and screencapture cannot produce a frame with no display attached, which is the gap a dummy display plug fills. display dialog returned button returned:, gave up:true, so the dialog really was drawn on a screen nobody can see.

Where I was wrong: they do come back

My 20-second cap turned seven returning calls into seven apparent hangs. Raising it changes the finding completely:

Script	Returned after	Error
No wrapper (default timeout)	66.03s	-609, connection is invalid
with timeout of 5 seconds	5.23s	-1712, AppleEvent timed out
with timeout of 12 seconds	12.25s	-1712
Finder, with timeout of 5 seconds	5.12s	-1712
JXA Application("System Events").processes.length	never, within 30s	no with timeout equivalent exists

Apple's AppleScript Language Guide says that by default "AppleScript waits for two minutes before reporting an error and halting execution". I measured 66 seconds, and the error was not the timeout error. So the documented default duration and the documented default error are both wrong for this path on 26.4.1. Wrapping the call in with timeout is what gets you the honest -1712, on the clock you chose.

The health check that always passes

Here is the trap I would have fallen into if I had tested the way most scripts do:

Event	System Events	Finder	SystemUIServer	Dock
version	1.3.6, 0.03s	26.4, 0.03s	1.7, 0.03s	1.8, 0.03s
name	0.03s	0.03s	0.03s	0.03s
A real query	-1712	-1712	-1712	not probed

version and name are answered locally out of the application bundle. They never leave the client process, they succeed for apps that are not even running, and they take 0.03 seconds. tell application "System Events" to return 1+1 also returns instantly, because no event is sent. If your preflight check is osascript -e 'tell app "System Events" to version', it will pass on a machine where every real automation call is broken.

Where it actually blocks

I sampled a stuck osascript for three seconds. All 2336 samples sat in one stack, so it is blocked rather than spinning:

OSAExecuteEvent -> ASExecuteEvent -> UASRemoteSend -> ComponentSend
  -> aeSend -> AESendMessage -> __CFRunLoopRun -> mach_msg2_trap

Then I sampled System Events itself, which my probe had launched successfully at 21:03. Its main thread is idle in the normal AppKit loop at _DPSNextEvent, so it never received the event. Three worker queues named receiveFrom-79441, receiveFrom-79732 and receiveFrom-80645 were stuck inside the Apple Event framework at _dispatch_event_loop_wait_for_ownership, one per dead client, alongside a queue named designatedCodeRequirementsCacheQueue. The receive side is stalled while validating who sent the event, and the stalled queues accumulate.

Nothing ever denies anything

I expected to find a TCC consent request with nobody to answer it. There is no request. Over a 30-minute window covering every probe, /usr/bin/log show filtered to tccd returned zero lines matching appleevent or automation, while happily logging kTCCServiceListenEvent 42 times and kTCCServiceScreenCapture 7 times. The absolute path matters here, since zsh has a builtin that shadows log, and reading what tccd records about a terminal is normally the fastest way to see an authorization decision.

The sender identity lookup does work. appleeventsd asked tccd for it and got an answer in about 14 milliseconds:

21:03:03.017 appleeventsd (TCC) TCCCreateDesignatedRequirementIdentityFromAuditTokenForService() IPC
21:03:03.031 tccd  REPLY: (0) function=TCCCreateDesignatedRequirementIdentityFromAuditTokenForService

So identity resolution succeeds, and then no authorization request for automation is ever made. No request means no decision, no decision means no denial, and no denial means no -1743. Incidentally, tccd attributes the responsible process to my agent binary in 45 of those lines, which matches what I found when I compared launchd and cron on this machine: the caller, not the tool, carries the attribution.

-1743 is not in the tables Apple ships

Two of the three places the system can name an error code do not contain the popular one:

$ macerror -1712
Mac OS error -1712 (errAETimeout): the AppleEvent timed out
$ macerror -609
Mac OS error -609 (connectionInvalid): connectionInvalid
$ macerror -1743
Unknown error (-1743) at /usr/bin/macerror line 37, <DATA> line 1.

Apple's published AppleScript error code table lists -1712 and -609 and also omits -1743. Only the SDK header has it, at MacOSX.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/Headers/AppleEvents.h:121:

errAEEventNotPermitted = -1743,  /* Mac OS X 10.8 and later, the target of the
                                    AppleEvent does not allow this sender to
                                    execute this event */

The same header documents the consent model, and one sentence in it describes my machine exactly. On AEDeterminePermissionToAutomateTarget: "Do not call this function on your main thread because it may take arbitrarily long to return if the user needs to be prompted for consent." Arbitrarily long, on a machine with no user, is the behaviour I measured. The header also defines errAEEventWouldRequireUserConsent = -1744 and a send flag kAEDoNotPromptForUserConsent, so a non-blocking path exists in the C API. osascript does not expose it.

The error text is localized and you cannot override it

This machine runs a Korean locale, so my errors arrived as AppleEvent 시간이 초과되었습니다. (-1712). osascript -AppleLanguages "(en-US)" fails with illegal option -- A, and LANG=en_US.UTF-8 changes nothing. If your monitoring greps for the English string, it will find nothing on a non-English Mac. Match the numeric code.

The proper fix is to grant automation consent once from a real session, in Privacy & Security, before the machine goes headless. That advice is everywhere, and it is correct. What is missing everywhere is that if you skip it, your unattended job does not get told no. It gets told nothing, slowly.

The imbalance shows up in the record. Stack Exchange API title searches give 7 on Stack Overflow and 2 on Ask Different for "not authorized to send apple events", against 2 total for "AppleEvent timed out", and Hacker News Algolia returns 0 hits for that phrase. The canonical Mojave thread has 62 votes and 87,772 views. An Ask Different question naming -1743 has sat four years with zero answers. The closest match to my setup is osascript failing through JumpCloud, an unattended management agent, and the nearest timeout report is XCTest bots failing with -1712 on CI. Unattended machines hit the timeout; interactive machines get the denial, and the denial is what got written down.

Measured on 2026-09-25 on one machine: a Mac mini (Mac16,10, M4) running macOS 26.4.1 build 25E253, arm64, SIP enabled, headless, 27 days uptime, from a non-interactive shell inside a logged-in Aqua session. All probes ran in a scratch directory under /tmp through a Python harness that kills each process group on timeout, since macOS has no timeout(1). Timings are single runs, not averages. Error code names come from /usr/bin/macerror and the AE framework header in the installed SDK on this machine; the consent quotes are from that header, not from memory. Three things I could not establish: whether display notification actually rendered, because there is no screen to check; what the receive-side queue is waiting on, since I can name the stuck dispatch queues but cannot see inside them; and -1743 itself, which I never reproduced, because this machine has no automation denial recorded and never gets as far as asking. I also deliberately skipped keystroke injection probes, which would have typed into the live GUI session. The first version of this matrix used a 20-second cap and concluded these calls hang forever; the 150-second run disproved that, and the 66-second figure is what replaced it.