I would like to close (not quit) a specific app using either applescript run in automator or in automator itself

My pitiful attempt:

tell application "lghub"
end tell

Its result: "lghub got an error: Can’t continue close."

I also attempted to run the command w shortcut, but automator tells me it cannot run keyboard shortcuts.

edit - i dont want to quit the app, i want to close the window so the icon hides but the app remains active in the background. hiding does not hide the icon.

  • 2
    Define "close (not quit)"
    – Tetsujin
    Nov 10, 2022 at 8:18
  • i dont want to quit the app, i want to close the window so the icon hides but the app remains active in the background
    – SUBZ3RO
    Nov 10, 2022 at 8:22
  • Are you talking about the dock icon ? If so, then say "the dock icon" so we're not all scrambling to read your mind. But I'm not aware that dock icons do hide themselves when an application's windows are closed, or perhaps I've got different settings to you. Can you give an example of an app and situation where closing the app's windows causes its dock icon (or whatever icon you're referring to) to hide ? Once you describe what has to happen, I imagine getting AppleScript to achieve the same outcome will be relatively simple.
    – CJK
    Nov 10, 2022 at 12:37
  • sorry, im new to mac. yes, when you close (the red window button) the logitech g hub app, it hides the icon from the dock whilst keeping it running in the background.
    – SUBZ3RO
    Nov 10, 2022 at 12:48
  • What happens if you close window 1?
    – Mockman
    Nov 10, 2022 at 19:05

1 Answer 1


when you close (the red window button) the logitech g hub app, it hides the icon from the dock whilst keeping it running in the background.

This behaviour has been specially implemented in the Logitech G Hub app. It's not typical of apps in general, although I have come across a couple of others that do this as well.

Is It AppleScriptable ?

The first thing you need to determine is whether the Logitech G Hub application is scriptable, i.e. can it understand and be controlled by Apple events? Apple events are the inter-application messages that AppleScript uses to communicate with scriptable applications, and send instructions to perform a particular function.

The quickest discriminator in this regard is to use AppleScript to dispatch an instruction to the Logitech G Hub app telling it to close its windows.

To do this, create a new document in Script Editor, and make sure the Logitech G Hub application is up and running with a visible window on-screen.

Then type and execute the following code:

tell application "lghub" to close its windows

If the app is scriptable, then that's all the code you need, and your problem is solved. However, if it throws an error, it'll be because it won't be able to get the application's windows.

Otherwise, ...

In this eventuality, the application is not scriptable. So we'll need to resort to using System Events instead.

System Events is a multi-purpose, background-only (i.e. invisible), scriptable application that has a lot of feature sets. One of the most popular amongst novice scripters is its ability to hack the user interface and manipulate graphical on-screen elements of almost any application.

These elements include buttons, windows, scroll bars, text boxes, etc. It requires privileges to be granted in order to do this, so you'll get a few requests for authorisation upon attempting this the first time for any given application. It is a potential security issue once you grant authorisation, so bear this in mind considering what I've just described as being in the remit of System Events' capabilities, namely to assume control of any visual element on-screen.

Assuming you're fine with this...

Start with a blank document in Script Editor, and execute the following command to obtain the bundle identifier of the Logitech G Hub application:

get the id of application "lghub"

This will return a string along the lines of "com.logi.ghub" or something. It's another means by which we can reference the application instead of using its name ("lghub"). It's more robust to use the application id rather than its name in general, but sometimes it's necessary in System Events, which doesn't interface with the application object from above, but with a process (or application process) object that is something separate. Often, these are named the same as the application that spawns the process, but occasionally they're not. Bundle identifiers, however, are always identical.

Here's the code to close the window with System Events:

tell application "System Events" to tell (the first process ¬
        whose bundle identifier is "com.logi.ghub") to tell ¬
        the front window to if (exists) then tell attribute ¬
        "AXCloseButton" to click its value

This targets the Logitech G Hub application process, which is a shell that contains everything needed for the application to run. This includes the physical UI elements, such as the window, which we first identify actually exists (to avoid throwing an error if it doesn't), and if so, we read off a reference to the red close button stored as one of the window's attributes. Once we have that reference, we can tell the button to behave as if we had clicked it, namely, to close the window.


To restore the window, you can do so like this:

tell application id "com.logi.ghub" to reopen

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .