Installing casks (BetterTouchTool) via brew and MacOS TCC (Transparency Consent and Control)

[plasticrake]

Output of brew config

HOMEBREW_VERSION: 6.0.11-28-gf9e050f
ORIGIN: https://github.com/Homebrew/brew
HEAD: f9e050ff085346db38abdab99fac279aa08b6b93
Last commit: 20 hours ago
Branch: main
Core tap: N/A
Core cask tap: N/A
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DOWNLOAD_CONCURRENCY: 20
HOMEBREW_EDITOR: code -w
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 10
HOMEBREW_REQUIRE_TAP_TRUST: set
Homebrew Ruby: 4.0.6 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.6/bin/ruby
CPU: deca-core 64-bit arm_firestorm_icestorm
Clang: 21.0.0 build 2100
Git: 2.55.0 => /opt/homebrew/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.5.2-arm64
CLT: 26.6.0.0.1781586589
Xcode: 26.6
Metal Toolchain: N/A
Rosetta 2: false

Output of brew doctor

n/a

Description of issue

Having an issue with BetterTouchTool that might be related to MacOS TCC. The developer states that this issue has only been reproduced by people installing BetterTouchTool via brew. I've encountered it twice and a friend also has had the same issue.

Curious about how likely this is? What would the difference between downloading this app and manually dragging it to the Applications folder vs brew?

Issue I reported to BTT Developer:
https://community.folivora.ai/t/all-inputs-blocked-have-no-effect-except-mouse-cursor-and-power-button/47421

Relevant casks

bettertouchtool

[wagnerand]

The app now warns explicitly with the following popup, that shows after clicking a prominent warning in the menu bar item context menu.

A Homebrew installation of BetterTouchTool was detected on this system (/opt/homebrew/Caskroom/bettertouchtool).

Installing BTT via Homebrew is not officially supported and can cause serious problems:

• When Homebrew upgrades or reinstalls BTT (e.g. 'brew upgrade --greedy' or 'brew reinstall'), it deletes the app and installs a fresh copy. macOS can then silently invalidate permissions previously granted to BTT, in particular the Accessibility permission.

• With an invalidated Accessibility permission, macOS may disable BTT's event tap as soon as any permission dialog shows up on screen. In the worst case this can temporarily freeze all mouse and keyboard input on your Mac.

Recommendations:
• Use BTT's built-in updater instead of Homebrew to update BTT.
• After any Homebrew upgrade or reinstall of BTT: quit BTT, remove and re-add BetterTouchTool in System Settings → Privacy & Security → Accessibility, then start BTT again.

[p-linnane]

Thanks for investigating. A few points suggest this is a macOS and BTT interaction rather than a Homebrew installation issue:

• Homebrew installs BTT’s unchanged vendor ZIP. Versions 6.629, 6.640, and 6.655 have the same bundle ID, Team ID, and designated requirement.
• Homebrew preserves the .app directory during upgrades when the terminal has App Management or Full Disk Access. Delete and reinstall is only the fallback when macOS denies that.
• The same input freeze has been reported after manually revoking Accessibility and with a Setapp installation.

The key question is whether AXIsProcessTrusted() becomes false after an in-place upgrade:

• If yes, with the directory and signing identity preserved, that points to macOS TCC.
• If no, the freeze points to BTT’s event tap handling.
• If trust is lost only after delete and reinstall, that is normal macOS uninstall behavior.

Can upstream test those cases? Until then, saying Homebrew installations cause the problem seems stronger than the evidence.

[fifafu]

@p-linnane unfortunately I don't know the exact mechanisms or setups the users have, but I can say with high confidence that the issue currently only affects installations via Brew. In every recently reported case the installation was done via Brew. Given the huge amount of installations done outside of Brew this is definitely not a coincidence. As far as I can tell AXIsProcessTrusted does not become false, which makes the freeze so hard to detect / prevent (BTT already has watchdogs that regularly check AXIsProcessTrusted to disable event taps and/or restart the app, but they do not trigger in this scenario). This in particular might be a macOS bug.

It is also quite possible the issue only happens for users that don't have App Management or Full Disk Access permission granted - I currently don't have information about the affected users setup there but will try to get some information from affected users.

[p-linnane]

Thanks. AXIsProcessTrusted() staying true rules out TCC revoking the grant, so this is the tap, not the trust record.

Likely cause: the bundle gets replaced under a running process. The cask has uninstall quit: "com.hegenberg.BetterTouchTool", but that is an Apple Event and only fires if the terminal has Automation access. Denied, the quit fails and we swap the app out from under a live BTT. Without App Management or Full Disk Access we also fall back to delete and reinstall rather than updating in place. Both match your missing-permissions hunch, and neither happens with a manual drag or your updater.