BetterTouchTool, and the permission it quietly shares with an AI desktop agent

What BetterTouchTool actually does

BTT has been around for over a decade, and it has accreted a lot. The core idea has stayed the same the whole time: take an input you can produce (a three-finger swipe, a keyboard chord, a mouse click in a screen corner, a Touch Bar tap) and bind it to an action you want your Mac to perform. The app is a giant, very well-built mapping table between triggers and actions.

In practice people reach for it for a handful of things:

• ·Window snapping and management. Drag a window to an edge and have it tile, or bind a shortcut to move and resize windows to exact fractions of the screen. This is the most common reason people install it.
• ·Custom trackpad and mouse gestures. Define multi-finger swipes, taps, and click-and-drag motions on the trackpad or Magic Mouse, and fire any action from them.
• ·Keyboard shortcuts and remapping. Replace or add system-wide and per-app shortcuts, including chained and conditional ones.
• ·Touch Bar, menu bar, and notch widgets. Build custom controls and live readouts where Apple left blank space.
• ·Clipboard manager and screenshot tools. Keep a history of copied items, and annotate screenshots on the fly.

The through-line: everything BTT does, you set up first. You decide the gesture, you decide the action, and BTT executes that pairing faithfully, forever, until you change it. That determinism is the whole appeal. It is also where this story turns.

The one thing the feature lists skip

When you first launch BetterTouchTool, it asks for Accessibility permission: System Settings, Privacy and Security, Accessibility, flip the toggle for BTT. People click through this without thinking about what it actually grants. It is worth thinking about, because it is the most powerful checkbox on your Mac.

Accessibility permission gives an app a read-and-write handle on the macOS accessibility tree: the structured, hierarchical model of every window, button, text field, and menu in every running app. With it, a program can inspect what is on screen and synthesize clicks and keystrokes into other apps. That is how BTT moves a window that belongs to Safari, or sends a shortcut into Final Cut. It is reaching through the accessibility API to touch another app it does not own.

Here is the part nobody writing about BTT mentions: this is the exact same permission, the exact same accessibility tree, that an AI desktop agent uses. When Fazm asks for Accessibility access, it is asking for precisely what BTT asked for. The grant is identical. What each tool does with the tree once it has it is where they completely diverge.

Two ways to drive the same tree

Given the same accessibility tree and the same ability to click and type into other apps, there are two fundamentally different ways to decide what to do next.

BTT is rule-based. You author the decision ahead of time. Trigger X always fires action Y. There is no interpretation step at runtime: the swipe happens, the bound action runs, done. This is wonderful for things you do a hundred times a day and want to be instant and identical every time. It is useless for anything you did not anticipate when you sat down to configure it.

An agent is intent-based. You state the outcome (in Fazm, in plain language or by holding a key and talking), and a model decides at runtime which accessibility actions to string together to reach it. There is an interpretation step every time, which makes it slower and less deterministic than a hard-wired gesture, but it handles open-ended, never-before-seen tasks that you would never bother to script.

Neither is better in the abstract. They are tools for different shapes of work. The comparison below is not "which one wins," it is "which one fits the task in front of you."

What "intent-based" looks like underneath

Say you tell the agent: "put my notes window on the left half and the browser on the right." In BTT you would have pre-bound two snap actions and triggered each one. In an agent, the same accessibility tree gets walked at runtime to find the two windows and move them. The sequence below traces that single request from spoken words to AX calls.

A BTT rule does the last two steps directly, with no enumeration and no matching, because you already told it exactly which window and exactly where. That is faster. The agent path costs you an interpretation round trip, and buys you the ability to phrase the request differently every time, or to ask for something you never configured.

The macOS 26 quirk both kinds of tool hit

Because BTT and an agent lean on the same Accessibility permission, they inherit the same sharp edges in how macOS reports that permission. The worst one showed up on macOS 26 (Tahoe): the standard check, AXIsProcessTrusted(), reads from a per-process cache that can go stale after an OS update or an app re-sign. The user has granted the permission, the toggle is on, and the API still answers "not trusted." Any AX-based tool can get stuck here, showing a "please grant access" screen for a permission that is already granted.

Fazm handles this by not trusting the cached answer. In Desktop/Sources/AppState.swift, when the cheap check is ambiguous, it probes the live TCC database the only way you can from user space: it tries to create a listen-only CGEvent tap. Tap creation either succeeds (permission is genuinely live) or fails, and unlike the trusted-process call it is never served from a stale cache.

// Desktop/Sources/AppState.swift

/// Probe accessibility permission by attempting to create a CGEvent tap.
/// Unlike AXIsProcessTrusted(), event tap creation checks the live TCC
/// database, bypassing the per-process cache that can go stale on
/// macOS 26 (Tahoe).
private func probeAccessibilityViaEventTap() -> Bool {
    let tap = CGEvent.tapCreate(
        tap: .cgSessionEventTap,
        place: .tailAppendEventTap,
        options: .listenOnly,
        eventsOfInterest: CGEventMask(1 << CGEventType.mouseMoved.rawValue),
        callback: { _, _, event, _ in Unmanaged.passRetained(event) },
        userInfo: nil
    )
    if let tap = tap {
        CFMachPortInvalidate(tap)
        return true
    }
    return false
}

There is a second guard in the same file. When an AX call returns the ambiguous cannotComplete error, it could mean the permission is broken, or it could mean the frontmost app simply does not implement accessibility well (some Qt, OpenGL, and Python-based apps do not). Before concluding the grant is dead, Fazm re-runs the same check against Finder, a known AX-compliant app. If Finder also fails, the permission really is stuck; if Finder works, the original failure was that one app's problem, not a permission problem. That disambiguation is the difference between an honest "you need to relaunch" message and a false alarm that sends you digging through System Settings for nothing.

You will not find that in a BetterTouchTool overview, because it is not about BTT. It is about the shared substrate both tools stand on, and it is the kind of detail that only matters once you understand that "an app that customizes your trackpad" and "an app that runs an AI agent on your Mac" are reaching through the exact same door.

So which should you run?

Honestly, for a lot of people the answer is both, for different jobs. BTT owns the muscle-memory layer. An agent owns the open-ended layer. Here is the rough test I use when something feels automatable.

If the task has a fixed shape, a rule will always beat a model on speed and reliability, so keep BTT for those. If the task is fuzzy, one-off, or crosses app boundaries, that is exactly where a rule falls apart and an agent earns its keep. They coexist on the same permission without stepping on each other.

BetterTouchTool, common questions