Golden Gate Bug?

Trying to use long-existing macro to access a local variable:

set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
	set theLink to getvariable "localLink" instance kmInst
end tell

gives error: "Macro Cancelled. Execute an AppleScript failed with script error: text-script: 103:142: execution error: Keyboard Maestro Engine got an error: "localLink" doesn't understand the "getvariable" message. (-1708)."

Confirmed here.

This does appear to be a real issue in Golden Gate (including the upcoming minor update): Any AppleScript action that tries to load local or instance variables will fail with the above error message.

If you skip the KMINSTANCE bit and use a global variable instead, it works:

tell application "Keyboard Maestro Engine"
	set fooBar to getvariable "theLink"
end tell

display dialog "The value is " & fooBar

Hopefully @peternlewis can find out what's going on with the KMINSTANCE system attribute. My tear is that this is some security-related change Apple made in Golden Gate, and there is no fix. If that's the case, it's going to mean a lot of changes to existing macros to switch affected routines over to global variables, and then to delete those globals when done (as I hate massive lists of not-needed global variables.

-rob.

Not upgraded a test machine yet (maybe a job for tomorrow), but it would be worth seeing if it is getting the instance UUID or getting the instance variable value that's failing.

Does this simple Action work?

It appears to get the instance UUID just fine:

-rob.

Cool. Can you now try this?

Scratch 2.kmmacros (2.4 KB)

And that worked:

So it's the variable bit that's failing. Hopefully something Peter can resolve—using an interim variable is a bit nicer than globals, but still a lot of macro editing :slight_smile:

-rob.

Not so sure. We seem to have shown that we can get the executing instance UUID with AS -- so it isn't line 1 of the erroring script that's the problem.

And, given a valid UUID, we can get the value of a local variable -- so it isn't line 3 that's the problem.

And we can set kmInst, else the script would error before getting to localLink.

Since the other two lines just start and end the tell block, there isn't much left!

If kmInst was "wrong" or empty then getvariable "Local_foo" instance kmInst would evaluate to the empty string, not throw an error. If kmInst was the wrong class and couldn't be coerced to plain text we'd get a different error (-1700).

At which point I've argued myself out of all my ideas. Damn!

Does process tokens also break? For example, changing line 3 to:

set theLink to process tokens "%Variable%localLink%" instance kmInst

My tester upgrade may get moved forward to this evening...

That also fails:

2026-09-23 09:43:45 Action 1998555450 failed: Execute an AppleScript failed with script error: text-script:103:160: execution error: Keyboard Maestro Engine got an error: "%Variable%local_theLink%" doesn’t understand the “process tokens” message. (-1708)

2026-09-23 09:43:45 Execute an AppleScript failed with script error: text-script:103:160: execution error: Keyboard Maestro Engine got an error: "%Variable%local_theLink%" doesn’t understand the “process tokens” message. (-1708). Macro “test” cancelled (while executing Execute AppleScript).

(I had renamed the variable in my version.)

-rob.

Just to add to this - I am on

Keyboard Maestro: 11.1.1
macOS: macOS 27.0

And the below works fine for me without any errors.

set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
	set theLink to getvariable "localLink" instance kmInst
end tell

That is bizarre. I tested on both 27.0 and 27.2 (upcoming), also using 11.1.1, and had the stated error on both Macs.

I wonder if some obscure permissions setting is causing this, somehow?

-rob.

I'm struggling to see how permissions would block ops when both the get and use are in the same script but allow when they are separate -- if anything you'd expect it to be the other way round.

Mind you, I struggle to understand PPPC at the best of times :wink:

Upgrade in process -- seldom have I been so hopeful that an upgrade would break something....

Just to 100% confirm my result, this is the test Macro I ran:

Test for AppleScript Local Variable macOS 27.kmmacros (4.2 KB)

Which for me returns this result:

Interesting thread (as well as concerning.

I tried @Zabobon macro and it worked here as well.

Using your downloaded macro, mine fails with the same error.

-rob.

I went to test @Zabobon's macro under KM 11.1.1 with Sequoia 15.8 and Safari repeatedly refuses to download the macro. Tried a dozen or so times. Either nothing happens—Downloads icon appears in the toolbar then goes away after a couple seconds—or this, with the shown dialog presented when trying to show the file in the Finder.

Another data point - I downloaded @Zabobon's macro with Safari on macOS 27 without a problem, ran it and it worked as expected.

To echo the advice @peternlewis always gives, if this isn't working for you on macOS 27, have you restarted the machine since the upgrade? Not saying it will fix it but I've seen similar oddities myself after an upgrade which were cleared by a restart; so if you haven't restarted, I'd try that first.

Confirmed working for me too -- freshly updated 27.0 on an M1 Air, KM v11.1.1

So I'm no help. Unless...

@griffman -- can you try the following in Script Editor, to take osascript out of the equation?

tell application "Keyboard Maestro Engine"
	process tokens "%ShortDate%" instance "1"
end tell

The Engine doesn't care if you target an invalid instance with process tokens, so the above just makes sure we're using the correct class. And Script Editor may be more informative about any PPPC problems.

That runs fine in Script Editor. (I have rebooted this machine during all this, too, as I went from 27.0 to the 27.2 beta. It failed in both.)

-rob.

As noted in my above reply, I had rebooted after an upgrade to the beta, but I've since restarted twice more, just to be sure. Still no go.

-rob.

As a further test, I created a new user on the machine, then tried to run the macro from there. Same result.

-rob.