1 • Environment
| Item | Value |
|---|---|
| macOS | 15.5 |
| Hardware | MacBook Pro M4 Max (2024) |
| BTT | 5.468 (stable) |
| iTerm2 | 3.5.0beta11 |
2 • Summary
Even with all check‑boxes in Settings ► Window Snapping & Moving (especially to note that in "Moving & Resizing Modifier Keys" none of the keys turned on) turned off (including Advanced Snap Settings and other), it anyway look slike BetterTouchTool still installs a system‑wide CGEvent‑tap that intercepts ⌘ + ⌥ + Drag, because seems ⌘ + ⌥ still rerpoted to iTerm2 (cursor changes).
As a result, iTerm2 never receive that drag gesture.
This heavily blocks me from using iTerm's "rectangular selection" (block‑select) relies on ⌘⌥‑drag; the cross‑hair cursor appears, but the selection itself never starts because BTT has already swallowed the drag event.
Quitting BTT or disabling BTT just for iTerm2 immediately restores the expected behaviour, confirming the hook originates from BTT.
3 • What I already checked
defaults read com.hegenberg.BetterTouchToolshows
cmdMove = 0,optMove = 0,BSTDisableSnapAreas = 1, etc.
— so no visible config flags enable CMD‑OPT move/resize.- Search All Triggers (⌘F in prefs) for "drag", "cmd opt", "⌘⌥" → no matching trigger.
4 • Impact
- Blocks iTerm2’s rectangular selection (daily nuisance for developers).
- Probably conflicts with any other app that relies on ⌘⌥‑drag for its own features (e.g. Affinity Designer multi‑select).
- Users must either disable BTT per‑app or abandon BTT entirely to restore expected behaviour.
5 • Expectation / Proposal
- When all Window Moving/Resizing features are disabled and no modifier keys are assigned, BTT should not intercept dragging for iTerm.
- Ideally, the hard‑coded fallback should respect the same flags as UI (Enable Move/Resize with CMD + OPT).
Thanks for looking into this!
