Bug Report: Regression in Paste Custom Text (118) / NSPasteboard injection on v6.921

[Doug_Hartley]

Describe the bug

Severe Regression: Sequential macro workflows and text insertion triggers that executed reliably for 18+ months are experiencing severe input dropping, clipboard paste failures, and execution latency.

Specifically, when an action sequence checks or displays a variable containing a valid string (e.g., displaying NOW_Date via a HUD Overlay shows "Oct.12.2026" correctly), the subsequent Insert / Type / Paste Custom Text (BTTPredefinedActionType 118) action fails to paste anything into the active target field.

However, if the action step is switched from Paste Custom Text to Type Custom Text (193), BTT successfully outputs the variable contents character-by-character into the field.

Observed Behavior

1. Paste Engine Failure on Variables (118): HUD overlays successfully evaluate and render BTT variable values (e.g., Oct.12.2026), but the immediately following paste action fails to write to NSPasteboard or drops the synthetic Cmd + V trigger entirely.

2. Type Engine Workaround (193): Switching identical steps to "Type Text" inserts the text string properly, confirming the variable assignment logic is intact while the clipboard/paste injection pipeline is broken.

3. Execution Latency & Dropped Keystrokes in Sequences: Keystrokes following clipboard or selection steps (e.g., Shift+Cmd+V or Cmd+C) are frequently skipped unless artificial delays (e.g., 0.38s–0.60s) or duplicated identical action steps are inserted.

4. Browser DOM Interception: In Google Chrome / Google Sheets, programmatic paste calls (118) periodically trigger Chrome's "Enable copy, cut, and paste?" extension prompt, interrupting macro focus and dropping downstream triggers.

Troubleshooting Steps Conducted (Environment Isolation)

1. Purged SQLite Databases: Completely deleted corrupted background clipboard database files (~/Library/Application Support/BetterTouchTool/BTTClipboardManager_*.sqlite*). While this stopped mid-macro database migration loops in diagnostic logs, NSPasteboard paste drops persist on build 6.921.

2. Isolated OS/Hardware Environment: Tested triggers on both external multi-display setups and standalone MacBook hardware to rule out display scaling, external key-listener conflicts, or docking station interference.

3. Verified System Permissions: Fully reset and re-granted BTT's macOS Accessibility and Input Monitoring permissions in System Settings.

4. Checked macOS Secure Input: Verified via ioreg -l -w 0 | grep SecureInput in Terminal that no background process (e.g., 1Password, Okta, or Terminal) was holding SecureInput engaged during execution failures.

5. Chrome Extension & DOM Isolation: Verified behavior both with and without the "Google Docs Offline" extension active in Chrome (chrome://extensions), confirming that DOM key-listener traps do not account for raw NSPasteboard paste failures across other non-browser targets.

Affected Input Device

Keyboard Shortcuts / Named Triggers / Key Sequences / Action Chains

Device Information

• Type of Mac: MacBook Pro 14-inch (2021), Apple M1 Pro, 32 GB RAM

• macOS version: macOS Tahoe 26.7.1

• BetterTouchTool version: Version 6.921 (Licensed Lifetime)

• Active Chrome Extensions: Google Docs Offline, 1Password, Okta Browser Plugin, WalkMe, Zoom

Additional Information

• Workflows were stable for 18+ months prior to recent builds.

• System restarts and Accessibility/Input Monitoring permission toggles do not resolve the paste failure.

• No application crashes occur; issue pertains specifically to NSPasteboard write failures, event tap delays (CGEventTap), and synthetic keystroke drops (CGEventPost).

[Andreas_Hegenberg]

There has not been a change related to these for a very long time. Does this only happen in a specific app?

Do you have an action sequence that can reproduce the issue?

[Andreas_Hegenberg]

This sounds a lot like the other Chrome related issue you described here:

Dropped keystrokes and severe execution latency in macro action sequences

Pleased to report I don't have empirical evidence of this being a BTT-sourced latency problem. I found an anomaly in my enterprise-scale Google Sheets workbook that causes me to state the above. Sheets would lose its mind when I was using a saved view that crossed a thousand-row difference between rows. When I would try to ⌘--↓ it would add severe latency, causing BTT macros to exceed all timing instructions. This happened intermittently. Other saved views with similar boundary sp…

If the workbook causes high latency in Chrome for some reason, it could lead to such an issue. The way how "Paste Custom Text" works is by putting some content onto the clipboard, then sending cmd+v and then restoring the previous clipboard content again. If Chrome takes too long, BTT could already have restored the previous clipboard content again.

You can try to increase the time before BTT restores the clipboard contents. This command would set the restoration timeout to 1 second:

osascript -e 'tell application "BetterTouchTool" to set_user_defaults key "BTTPasteClipboardRestoreDelay" numberValue 1.0'

[Doug_Hartley]

I executed the osascript command you provided, and then ran follow-up isolation tests across native and web applications. Here are the results post-script execution:

1. Native macOS Application Test (Microsoft Excel for Mac)

• Executed the date-replacement macro using Paste Custom Text (BTTPredefinedActionType 118) in Excel.

• Ran 5 consecutive test executions without changing any macro steps or delays.

• Result: 100% Pass Rate (5 out of 5 successful/multiple insert/paste actions).

2. Web Browser Test (Google Chrome / Google Sheets)

• Executed the identical variable paste macro in Google Sheets (tested in both blank and enterprise sheets).

• Result: Paste Custom Text (118) continues to fail/drop the output, completely this time. All insert/type and insert/paste actions did nothing.

Summary Following the osascript execution, BTT’s core NSPasteboard paste engine and variable evaluation are operating properly in native macOS applications (Excel). The remaining issue is isolated specifically to Paste Custom Text (118) interacting with Chromium's web-event listeners in Google Chrome.

Let me know if you would like me to grab a fresh debug log package during a failing Chrome run.

Best,

Doug

[Andreas_Hegenberg]

Unfortunately there is nothing to log from the BTT side. If it works correctly in Excel and other apps, then your BTT is sending the correct events but Chrome fails to act on them.

I wonder whether there is some Chrome setting that could affect this, I haven't found a matching one yet. I'm mostly a Safari user, but just tested in Google Sheets in Chrome as well - "unfortunately" the issue does not appear here and BTT is able to paste correctly.

You could try to set an even higher restore interval (this would make it 2s), but I am not sure whether that can help:

osascript -e 'tell application "BetterTouchTool" to set_user_defaults key "BTTPasteClipboardRestoreDelay" numberValue 2.0'

//edit: is it maybe some enterprise security feature that prevents third party apps from pasting stuff into a managed Chrome Browser?

[Doug_Hartley]

Really appreciate the follow up, as always.

Meanwhile, I continue to sleuth and have word into my corporate IT to determine if there's anything new they've introduced that could be the culprit

Not that it's to be trusted by any means, but most recently, Gemini claimed:

1. The Pre–October 7 Pipeline (Why It Worked for Years)

Historically, BetterTouchTool’s "Insert/Paste" action executed a two-step sequence:

BTT wrote the text payload to NSPasteboard (generalPasteboard).

BTT synthesized a physical shortcut (⌘-V) into macOS’s window server using CGEventCreateKeyboardEvent and posted it via CGEventPost(kCGSessionEventTap, ...).

When Chrome received the incoming NSEvent at RenderWidgetHostViewMac:

Chrome mapped the NSEvent to Blink's WebKeyboardEvent.

The Legacy Behavior: Chromium treated any valid OS-level keystroke reaching the focused window as an authentic user action, tagging the event with has_user_gesture = true.

The DOM Handshake: Blink fired the DOM paste event with transient user activation intact. Google Sheets queried event.isTrusted, verified activation, synchronously read e.clipboardData, and rendered your text.

2. What Changed on the Evening of October 7

In the October 7 update, Chromium tightened its compliance with the W3C User Activation v2 model by inspecting the native macOS event source state at the Cocoa/AppKit boundary (ui/events/cocoa/events_mac.mm).

That said, I do see abnormal behavior while configuring "Insert Paste Type" actions... probably not related, but 10 hours into trying to solve this puzzle, it's important to mention.

For instance, this action will not allow me to change from Paste to Type. Insert Text by Pasting is locked in (greyed out). I've never had that happen before:

Another time, it shows itself as a "Type Custom Text" action; also with the change from text to paste drop down greyed out / unavailable.

The "Type Custom Text" action doesn't exist, to the best of my knowledge:

[Andreas_Hegenberg]

The gemini hint about looking at the Chrome source was good - although the reason it gave was wrong.

It is a Chrome 155 bug, not a BTT change. Chrome 155 added a check that drops a paste if the clipboard "changes" during it. On macOS, Chrome has a race where clipboard content written by another app right before ⌘V looks like such a change, so the paste is silently discarded. Google has already fixed it (crbug 568453825); the fix ships in Chrome 157 (beta from Oct 14, stable Nov 3). Until then: replace "Paste Custom Text" with "Set Clipboard Contents" → "Delay 0.2s" → send ⌘V, or keep using "Type Custom Text". I'll also try to add a small automatic delay for Chromium browsers in the next BTT build until this is resolved.

The bug report itself is restricted, so I haven't been able to read the details. Possibly it has some security implications or is a side effect of some security related fix: https://issues.chromium.org/issues/568453825

https://chromium-review.googlesource.com/c/chromium/src/+/8503629

The issue only appears if something in Chrome is actively observing the clipboard, which is why I couldn't reproduce it here. Examples:

• Gemini in Chrome: after any copy from a web page, it starts a watcher that stays on for the rest of the session.
• Enterprise Data Controls (company clipboard rules on a managed Chrome).
• A web page listening for clipboardchange.