Possible to Run 2 "Instances" of KM Editor?

Is it possible to save all my macros/groups/variables and the KM environment and start a new instance of KM Editor? Then move back and forth between KM-Instance#1 and KM-Instance#2?

I’d like to selectively restore a macro group from KM-Instance#1 into KM-Instance#2 (after backing up just this macro group from KM-Instance#1).

Then I want to debug, test, cleanup there. Switch to KM-Instance#1, repeat process for my next KM Macro Group (or associated groups) etc.

I’m having organisational problems with:

— organisation of my macros/groups etc. (too many)

— proliferation of old variables (didn’t delete them in the past)

— KM Editor typing speed (can be slow & often misses keystrokes)

— implementing a backup regime I trust (the restore dumps back in situ)

— finding old macros (using macro groups is not properly solving this)

— cleaning up & evolving my KM environment in an incremental fashion


On a Mac, it's of course possible to run multiple instances of any (I believe) application, instantiating each from the command-line, e.g.: open -na Safari.

So my guess is that the way to do it would be open -n /Applications/Keyboard Maestro.app/Contents/MacOS/Keyboard Maestro (using the path to the executable rather than the application bundle because you probably don't want two instances of the Keyboard Maestro Engine running as well).


Is it a good idea to do this? I honestly couldn't tell you one way or the other, and so it's perhaps my lack of knowing in this case that prohibits me from being cavalier and just trying it out, because I do not want to risk scrubbing the KM databases and with those my macro library. Backing up would, at the very least, seem prudent before attempting this.

If it goes the way you'd like it to, then hopefully creating a second instance will also create distinct copies of the Application Support files, meaning the two instances can exist side-by-side freely without causing any clashes.

But, in that case, perhaps you're better off creating a duplicate of the application bundle and giving it a different name, making the appropriate edits to the info.plist in the clone, and running that as e.g. "Keyboard Maestro concertatore.app". This would avoid the two "instances" having the same process name, which isn't a massive deal itself, but if you have any macros that reference the KM Editor window, the first method would not give you any control over which of the two instances receives commands/signals/events/etc.

Basically, no.

You could quit Keyboard Maestro and Keyboard Maestro Engine, move the Keyboard Maestro preference folders and files out of the way, move a different set in, and then launch Keyboard Maestro. But it is not really supported and certainly not easy (I have something like this for testing, but it is very complicated).

The relevant files and folders to move are:

~/Library/Application Support/Keyboard Maestro (folder)
~/Library/Preferences/com.stairways.keyboardmaestro.* (files)

Generally better would be to create a separate user account.

This is highly not recommended for many applications. Certainly for Keyboard Maestro it will lead to data loss. The same is true for many other applications. Unless an application is specifically designed to support this, if it has any data stored centrally (like Keyboard Maestro does), that data is likely to be corrupted.

This would not help, you would still get data loss when the two applications fought over control of the macros. Each change in either would overwrite the changes from the other. And that would just be one of the issues.

Hey Steve,

In a word? No.

Not with any sort of convenience.

However – many things are possible.

See @DanThomas' export for VSC macro:

MACRO: Macro Repository (i.e. Version Control) Beta

See this:

Keyboard Maestro Discourse Delete All Variables Except…

A selected macro can be quickly exported to disk.



1 Like

Thanks for clarifying the risks of doing this. I didn't know for sure, but I suspected that data corruption was at least going to be a possibility to consider, and hence why I wasn't intending to run the experiment myself to find out on behalf of someone else. I'm glad now to have a little more clarity than I had on this issue.