BTT prevents display sleep on lid close and reboots on sleep

Bugs or Unexpected Behavior
1

Prevents display sleep on lid close and causes a reboot on sleep

Describe the bug
I'm experiencing two distinct sleep-related issues on two different MacBook Pro M4 Pro machines running BTT v6.378 on macOS Tahoe 26.3.1. Both issues started in the last few weeks (maybe a month) after recent BTT updates. Both issues disappear completely when I quit BTT.

Issue 1: Display backlight stays on when lid is closed (MacBook Pro 16" M4 Pro)
When I close the lid, the display backlight does not turn off - I can see light bleeding through the cracks around the lid. The machine does not appear to fully sleep. When I quit BTT and close the lid, it goes dark immediately. Reproducible 100% of the time.

Issue 2: Mac reboots itself on sleep (MacBook Pro 14" M4 Pro, external monitor, lid always open)
This Mac is always connected to an external monitor with the lid open. When the machine goes to sleep, it reboots itself instead of sleeping normally. Quitting BTT before sleep resolves this completely.

Device information:

  • Machine 1: MacBook Pro 16" M4 Pro
  • Machine 2: MacBook Pro 14" M4 Pro (connected to external monitor)
  • macOS version: Tahoe 26.3.1 (both machines)
  • BetterTouchTool version: 6.378

What I've ruled out:
I systematically tested the following, none of which resolved the issue:

  • Notch Bar — already disabled, was never enabled
  • Window Snapping — disabled and tested, issue persists
  • Automations & Named Triggers — none configured
  • "Restart BTT after waking from sleep" — unchecked
  • No sleep/wake/lid triggers of any kind configured
  • pmset -g assertions shows no power assertions held by BTT

My BTT setup is minimal — I only use around 15–20 keyboard shortcuts. No Notch Bar, no Touch Bar widgets, no floating menus, no named triggers.

Conclusion:
The issue appears to be in BTT's core process itself (likely the system event taps for input interception), not in any specific user configuration. Simply having BTT running is enough to cause both problems.

Happy to provide logs, Console.app output, or any other diagnostics that would help.

2

why would these cause sleep issues?

Most likely this is a conflict with some other app or possible some hardware. Do you have logitech devices connected?

3

This sounds like a system crash, I have only seen such sleep related crashes due to driver issues. BTT usually cannot cause such by itself. Can you think of any special hardware that is connected to that machine and maybe has custom drivers?

Are there maybe any crash reports / spinreports / diagnostic reports in the macOS Console.app for the relevant time?

4

Thanks for replying.

On my work MacBook Pro (the one that reboots itself every night), I only have a monitor connected and the webcam (Insta 360). On the personal MacBook Pro (the one that bleeds the light through), I have nothing connected. I just switched back to the 6.176 version on my personal MacBook Pro, and the light bleeding stopped.

5

The problem with downgrading is that it will also downgrade your configuration to how it was at that version (unless you imported a fresh config), so if it was caused by some configuration in BTT that was done after the 6.176 version downgrading would resolve it.

I just checked on a few of my machines (Macbook Pro M1 Max, Macbook Neo, and M4 Max) but they all immediately sleep and turn off their displays. So this at least is not a general issue. Unfortunately sleep related issues are often hard to debug ;-(

Could you post the output of this command? (best after reproducing the issue)

pmset -g log | grep -i wake
6

I think I found it, the “Act as Hyper Key“ action does that. I have no idea how this works, but I was disabling all my triggers one by one to see if any of them do this, and it stopped when I disabled the Caps Lock > Hyper Key trigger. Then I enabled the trigger, but deleted the action, and my MacBook can now sleep. I can record a video showing that, if it helps.

7

But now I have another problem - the BBT just silently quits :exploding_head:

I am starting to hate this app, this used to be my favorite app, I was swearing but it, recommending it left and right, but now I spend more time debugging it then I am gaining from being productive using it :broken_heart:

Antonio_Gordon 8

9

Same behavior on both MacBooks.

10

I can reproduce the same with BTT: 6.400 and macOS 15.7.4 (24G517), MacBook M1 Pro

Here's the output of the command you asked Andreas, after I've did what Antonio demonstrated in the video.

2026-04-19 22:22:34 +0300 Assertions          	PID 556(powerd) Created InternalPreventSleep "com.apple.powermanagement.darkwakelinger" 00:00:00  id:0x0xd00009638 [System: PrevIdle DeclUser SRPrevSleep kCPU kDisp]          
Sleep/Wakes since boot:1   Dark Wake Count in this sleep cycle:0
2026-04-19 22:22:35 +0300 Assertions          	PID 556(powerd) Summary InternalPreventSleep "com.apple.powermanagement.darkwakelinger" 00:00:00  id:0x0xd00009638 [System: PrevIdle PrevSleep DeclUser SRPrevSleep kCPU kDisp]          
2026-04-19 22:22:35 +0300 Assertions          	PID 556(powerd) Summary InternalPreventSleep "com.apple.powermanagement.darkwakelinger" 00:00:00  id:0x0xd00009638 [System: PrevIdle PrevSleep DeclUser SRPrevSleep kCPU kDisp]          
2026-04-19 22:22:40 +0300 Assertions          	PID 556(powerd) TimedOut InternalPreventSleep "com.apple.powermanagement.darkwakelinger" 00:00:05  id:0x0xd00009638 [System: PrevIdle DeclUser SRPrevSleep IPushSrvc kCPU kDisp]
11

Thanks, I believe I now know what causes this in combination with the hyperkey function! Should be resolved in 6.413, issue was introduced somewhere around 6.359 and is a undocumented side effect / timing issue of a system function BTT uses.

6.413 modifies the timing to prevent this. (uploading now)