I’m having an issue with BetterTouchTool after updating to macOS 27: the app asks for all permissions again after every system restart. However, the permissions are correctly enabled in System Settings. I have to toggle them off and then back on again. There is no problem if I don't use autostart—meaning if I launch the app manually—as it doesn't ask for permissions then. Could there be a timing-related bug here?
I'm using the newest Version on a 14" M5 MBP with 24 GB RAM.
Could be a timing bug, but it would be a bug in macOS. This is all completely handled by the system, but also there has not yet been a macOS version without bugs related to this 
Usually resetting the permissions for an app will resolve these kind of issues. To do that make sure to quit BTT, then run this terminal command:
sudo tccutil reset All com.hegenberg.BetterTouchTool
Unfortunately, it doesn't work. The only thing that helps is a delayed start via a script. I have this problem with several apps in the menu.
Google is aware of the issue:
In macOS 27 Golden Gate, a redesigned menu bar architecture with dynamic overflow handling causes timing and initialization race conditions for third-party startup and menu bar management apps. [1, 2]
What is Happening
• New Menu Bar Architecture: Apple rewrote how menu bar status items load and display, shifting from separate small system windows to a dynamic layout with an overflow indicator. [1, 2]
•
• Timing Conflicts: Third-party utility apps (such as Bartender, Ice, or BetterTouchTool) attempt to hook into the menu bar before the system finishes initializing the new dynamic layout, leading to crashes, missing icons, or delayed startup. [1]
•
• Initialization Race Conditions: Menu items load out of order because background helper processes launch before the system accessibility and window server layers fully register the new menu bar bounds.
•
How to Mitigate the Issue
• Update Your Apps: Check for updates from utility developers who are rebuilding their apps using the updated macOS 27 APIs. [1]
•
• Manage Login Items: Go to System Settings > General > Login Items & Extensions to review and temporarily remove conflicting menu apps from your startup list. [1]
•
• Stagger Launches: Use a third-party launcher or delayed-launch script if an app must start at boot, allowing macOS 27 time to settle its menu bar layout.
•
If you'd like, I can:
• List specific menu bar apps known to have updates or patches for macOS 27
• Guide you through checking Console logs for the exact crash or timeout code
That AI answer seems irrelevant to your question. This is not about the menubar changes in Golden Gate, they are unrelated to permissions.
Yes, but menu bar apps are typically startup items that require system permissions. I have a total of eight apps from various developers experiencing this issue.
The problem I described really affects—without exception—login items that launch at startup, move to the menu bar, continue running in the background, and require extensive permissions (e.g., Accessibility, Automation, Full Disk Access, etc.). If these apps are launched with even a slight delay (whether manually or via a script, as in my workaround), there are no permission issues.
I am pretty confident to say this is something very specific to your machine. There are already tens of thousands of BTT users on Golden Gate and there have been no similar reports yet.
Unfortunately I don't really have an idea what exactly could cause it, but it doesn't seem to be a common issue. Maybe think about any special setups - do you maybe have System Integrity Protection disabled?
Nothing specific, other than the fact that I use a large number of menu items (more than 20). That might be exacerbating the issue.
I’ve also contacted the other developers whose apps are affected by the same problem; most of them are aware of the issue.
I think it will resolve itself completely with upcoming macOS updates.
In the meantime, I have a working workaround: a startup app (script) that triggers a shortcut to launch the affected apps with a 20-second delay. It works perfectly.
Sounds like for some reason the tcc.db database is blocked (or the tccd process not ready) after startup on your system.
Apple did relocate that database to a more protected location on macOS Golden Gate, maybe it is related to this.
(But I am not surprised about tcc issues anymore, with every major macOS version there have always been at least a handful of users running into bad TCC issues)