Copy Function Timeouts Without Updating System Clipboard

Copying plain text should be very fast. I do that often with KM, and it works well.
Does a manual copy (with the Edit > Copy, or ⌘C) work OK? If so, then likely there is something wrong with your Macro design.

Please upload your macro so we can inspect and test.

Also, Please read:
Tip: How Do I Get The Best Answer in the Shortest Time?

Yes, the regular system copy (with the Edit > Copy, or ⌘C) works fine. I created the simplest macro — just the Copy action, and tried it in a number of applications (including "Stickies"), and get the same timeout error each time. Here's the macro and the error:

timeout error

copy test Macro (v9.0.5)

copy test.kmmacros (1.5 KB)

What this means is that Keyboard Maestro simulated the Command-C key, and then the clipboard did not change.

If this happens in multiple applications, then perhaps Keyboard Maestro cannot simulate any keys, which would point to an accessibility problem likely resolved by toggling the accessibility permissions in the System Preferences as described at: Accessibility Permission Problem assistance.

Thanks for the suggestion. I am on Mojave (10.14.6), so I followed the instructions on the help page you referenced:

  • quit both Keyboard Maestro and Keyboard Maestro Engine
  • open System Preferences > Security & Privacy > Privacy pane
  • select Accessibility
  • delete entries for both Keyboard Maestro and Keyboard Maestro Engine
  • launch KM and ensure that the Accessibility for both KM and KME are ticked


Alas, the problem remains: the Copy action results in a timeout, when accessed anywhere (Finder, Stickies, TextEdit, etc.).

However, the Paste action works as expected.

I'm experiencing the same thing.


Here is how I fixed the issue:

Without the step that executes pbpaste and stores it in clipboard, no matter what I did, Copy did not work in the multiple applications that I tried (TextEdit, BBEdit, Excel, Notes).

I had been struggling with this issue of Copy (either the Copy action or by simulating Command-C key) not working for a couple of hours since today morning. The macro in question was last used 3 weeks ago, so I am not sure what happened during this time to cause this. I am on Catalina (10.15.7) with KM Version 9.2.

Initially, I thought that this might be due to an update I recently installed in MS Excel so tried using the apple script posted here: to no avail. However, this was a red herring as I soon discovered that Copy (function or simulated keystroke) did not work in other applications as well.

I had followed the steps suggested for fixing Accessibility issues (TIP: Resolving Catalina/Mojave Accessibility/Security Permissions Issues), but they did not help. However, I soon discovered that simulating keystrokes was definitely working since I was able to get KM to simulate typing characters inside the problematic applications. Even for Excel, on simulating Command-C, the selection would change to a dotted box to prove that Command-C had indeed been successfully simulated.

Adding delays after the Command-C did not help.

Also tried killing pboard process to make sure this was not a case of the clipboard process having issues. Restarted MacOS just to tick off that old chestnut.

Hope this helps!

@JMichaelTX : My apologies for bringing this to your attention, but do you think that this might be worth adding as a workaround to the official documentation or as a note to the wiki?

I have used KM Copy Action with all of those and it works well.
Running Keyboard Maestro 9.2 on macOS 10.14.6 (Mojave).

If it is not working for you, that means that something is interfering with KM on your Mac.
Please read Troubleshooting -- KM Wiki.

Hey @azorpheunt,

This is basically impossible – so why is the impossible happening on your system? These kinds of things don't occur in a vacuum.

A) Do not simulate Cmd-C unless it's the only option available. There are too many things that can go wrong with simulated keystrokes. Use the Copy action or the Select or Show a Menu Item action to select the menu item Edit › Copy.

B) Bring up the Clipboard History Switcher and see what's in the History. Copy 3-4 things to it in the normal fashion, and make sure it's working correctly.

C) Do you have any other apps or utilities that use or might interfere with the clipboard?

D) Do you have any other apps or utilities that use or might interfere with the Cmd-C keystroke?

E) Does the problem occur when you boot your system in safe-mode?

F) If you create a clean new user and install only Keyboard Maestro, does the problem still occur?


1 Like

Thank you very much for your wisdom @JMichaelTX and @ccstone

I tried the Troubleshooting instructions, and found things in KM that I never knew existed (which I guess is a testament to how well KM works as I've never had to debug an issue with a macro before). The Help Wizard did not reveal anything wrong with the Macro (which is a test macro with a step to copy something in different ways and a subsequent step to display the system clipboard).

The Clipboard History Switcher was much more interesting. I discovered that I could not activate the history switcher at all and then from another thread (Activate Clipboard History Switcher : Long delay) there was advice to do this :

defaults write com.stairways.keyboardmaestro.engine MaxClipboardHistory -int 20

And then everything started working. This still leaves the question of 'why now / what changed to cause this' unanswered, but I am happy to have things working now without hacks.

I have never used KM as a Clipboard manager before today, so am not sure what effect the above command had to fix the issue.

I just want to clarify that this is the desired, and expected behavior.
The KM Copy Action attempts to copy the selected object.
If that Action times-out, that means that either there was NO selection, OR, the selection was so large that it could not be copied within the timeout of the Copy Action.

This should be a rare event. However sometimes the User has NOT selected anything.
Thus, instead of terminating the macro (the default behavior), you can check the success of the prior action, and if it fails, then take some specific action.

In one of my Macros, if the Copy Action fails, then I select the text from the current insertion point to the end of the line, and then copy that.


Apparently at some time either you or some macro you ran set the clipboard history to zero, and that fouls things up more than meets the eye.

I suggest you rerun your defaults command and set the history to at least 100. I have mine set to 500.

If you haven't used a clipboard-history utility on the Mac before, you've missed out on very useful functionality.

I use LaunchBar as my daily driver, Keyboard Maestro as backup and for more literal searching, and Paste (at need) for syncing between my devices.


Thank you @ccstone

If you haven't used a clipboard-history utility on the Mac before, you've missed out on very useful functionality.

I totally agree with the usefulness of a clipboard manager. I do not use KM's clipboard manager since I prefer 'CopyQ' (open source, cross-platform) to reduce the jarring context switch between Windows and Mac when I am forced to use the former.

If I were to use Windows only, I would prefer 'Ditto' since its performance is much better than CopyQ (for instance when searching for regex).

If you've used CopyQ, I would be very interested to know how it compares to KM's clipboard manager.

Thank you!


I haven't. It won't run on my Sierra system, but I'll probably install it on my MacBook Air (Mojave) box and give it a look.


@peternlewis, can you confirm or refute that setting the KM Clipboard History to zero may cause problems? If so, can you please describe these problems?

Set the clipboard history to 0 simply means that Keyboard Maestro will not read the system clipboard when it changes - instead it will read it only when you perform an action that explicitly reads it (eg using the SystemClipboard token, or an action that has the system clipboard as an input).

However, if you set the Clipboard History size to zero, or you exclude an application from Keyboard Maestro’s clipboard history, then the Copy action will fail because it simulates a Command-C and waits for the clipboard to change, and the clipboard will not change because Keyboard Maestro will not read the clipboard.

It could be argued either way as to whether this is a bug in the Copy action or Keyboard Maestro behaving exactly as you have explicitly told it to. I'd probably lean towards the former, but this situation only happens if you explicitly tell Keyboard Maestro not to read the clipboard. You can use Command-C instead, since that is all the Copy action does - perform Command-C and wait for a clipboard change.

I will ponder whether to the behaviour of the action should change.


Wow! this is huge!
So, then the user should ==never set KM Clipboard History to zero==.
And, IMO, KM should prevent this from happening.

So if a user wants to minimize the storage used by the KM Clipboard History, then he/she should set to ==no lower than 1.==

I will update the KM Wiki to add this notice/alert.

Managing the KM Clipboard History

To all KM Users, here is my suggestion:

  1. Set the KM Clipboard History to a max of 100, unless you have some very specific workflow that needs more than 100. Honestly, I can't imagine what that would be. The KM default is 200 Clipboards.
  2. If you set the Clipboard to a large amount of data, then delete that Clipboard as soon as you don't need it any more. I almost always do this in the same Macro that created the Clipboard by using the Delete Past Clipboard action at the end of my macro.

If you find that either the KM Editor app and/or KM Engine is running much slower than previously, then double-check both the KM Clipboard History, and the KM Global Variables for large entries, and delete them if at all possible.


Hey Peter,

I have two specific comments.

  1. A user should not have to troubleshoot this problem – there should be no problem. We've had this come up 3 times or so on the forum in the last year, and it's been a pain to diagnose.
    ⠀⠀a. The curious thing is that one or two of the users had NO
    ⠀⠀idea this setting had been changed on their system. (One did know.)

  2. In my opinion this is one place you need to overcome your reluctance to add new preferences. All good clipboard managers I've ever used have had such a setting. It's a disservice to the user to not let them adjust the setting without having to jump through hoops – most will NEVER even know there IS such a setting.


1 Like

No, this is specifically the point, to disable Keyboard Maestro from reading the clipboard in general.

Setting it to 1 does not accomplish that, since Keyboard Maestro will still read the clipboard every time it changes, which for some badly behaved applications causes undesirably consequences. Generally it would be better to exclude them than set the history to 0, but the results would be the same either way.

This is exactly why I do not have a preference for this setting, and if I did it would only be within a range, and not down to 1 or 0.

Once people configure private settings they are off in the wilderness on their own, with consequences that cannot be predicted.

I think a range would be fine as long as it was flexible enough.

I despise the way Objective Development does LaunchBar's Clipboard History:


I want to be able to enter a specific number of items or days and not be limited to what they think is relevant. Unfortunately they haven't listened to my arguments over the years.

I have my Keyboard Maestro Clipboard History set to 500, and it's saved me from myself more than a few times.


1 Like