Activating application from Terminal occasionally fails on macOS 26

On macOS Tahoe 26 activating GUI apps from command-line often fails. It launches the app but not brings to the foreground as expected.

For example, running the following commands in Terminal is expected to launch Pages and bring it to the foreground.

open /Applications/Pages.app

or

osascript -e `tell application "Pages" to activate`

Moreover, they sometimes not return in Terminal.

These commands worked as expected until macOS 15 but no more in macOS 26.

The tricky part is that this failure doesn't happen 100% of the time; it occurs randomly. However, since multiple users of my app have reported the same symptoms, and I can reproduce it not only with my app but also with apps bundled to macOS, I don't believe this is an issue specific to my environment alone.

I’ve already filed this issue: FB21087054

However, I’d like to know if any workaround exists or my understanding is wrong, especially for case with osascript.

Answered by DTS Engineer in 866756022
I’ve already filed this issue: FB21087054

Thanks. That’s definitely the best path forward for this.

It’s hard to think of a way to work around given that a) none of your code is running, and b) it affects system apps.

This is likely fallout from a general effort to stop apps stealing focus from other apps. Check out the yieldActivation(toApplicationWithBundleIdentifier:) and other related method for more background on that. However, Terminal is the frontmost app, and it should be the responsible code for any command-line tools that you run, so I would expect this to work. And it does work most of the time, hence my comment that a bug report was the best path here.

If you’re able to reproduce not-returning case, a sysdiagnose log from that might yield a useful insight.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer
I’ve already filed this issue: FB21087054

Thanks. That’s definitely the best path forward for this.

It’s hard to think of a way to work around given that a) none of your code is running, and b) it affects system apps.

This is likely fallout from a general effort to stop apps stealing focus from other apps. Check out the yieldActivation(toApplicationWithBundleIdentifier:) and other related method for more background on that. However, Terminal is the frontmost app, and it should be the responsible code for any command-line tools that you run, so I would expect this to work. And it does work most of the time, hence my comment that a bug report was the best path here.

If you’re able to reproduce not-returning case, a sysdiagnose log from that might yield a useful insight.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you again for your quick response!

I understand that this may be an issue on the macOS side and that, unfortunately, there is no available workaround at the moment. I hope this behavior can be addressed in a future update. I also appreciate you sharing the background behind this phenomenon. It’s technically interesting to me.

If you’re able to reproduce not-returning case, a sysdiagnose log from that might yield a useful insight.

OK. I’ll send additional information, including a sysdiagnose, if I’m able to reproduce the not-returning case.

We have seen similar behavior with on of our Apps since we recompiled it for Tahoe. It needs to be started using an argument that contains the configuration. Therefore, we rely on the open command.

The App starts and the icon appears in the dock but the window does not appear. Only after you click the dock icon the window appears.

As a work around I call the open command twice. First with the argument and then without. This makes the window appear.

Interestingly, we don't have any issue with the app version that was compiled prior to macOS Tahoe.

Activating application from Terminal occasionally fails on macOS 26
 
 
Q