# BetterTouchTool is glitchy, especially in Obsidian. Please inspect the live BetterTouchTool confi... ## Retrieval Notes - Session id: `019dab61-0afb-7a92-a97e-92c49a93497b` - Source: `Codex raw session` - Last activity: `2026-04-20T15:07:04.753Z` - Model: `gpt-5.4` - CWD: `/Users/nickyoung` ## My Notes <!-- Add your notes here. This section is preserved across syncs. --> ## Conversation ### User BetterTouchTool is glitchy, especially in Obsidian. Please inspect the live BetterTouchTool configuration, not just any old exported preset. Important context: - On another machine, the real problem was in the live BTT database, not in the old exported preset. - The authoritative live file was: ~/Library/Application Support/BetterTouchTool/btt_data_store.version_6_311_build_2026032702 - The old exported preset was stale and did not reflect the current live state. What to check: 1. Inspect the live BTT database / active config and logs. 2. Look for duplicate active Global gesture containers or duplicate active Global gestures. 3. Specifically check for duplicate Global "4 Finger Swipe Down" gestures with no modifiers. 4. Confirm whether there are two no-modifier Global "4 Finger Swipe Down" gestures: - one sending Cmd+M - one sending Cmd+W 5. If both exist, disable the newer Global "4 Finger Swipe Down -> Cmd+W" only. 6. Keep the older Global "4 Finger Swipe Down -> Cmd+M". 7. Keep the Obsidian-specific "4 Finger Swipe Down -> Cmd+W". 8. Restart BetterTouchTool after the change. Also investigate these likely false-positive gestures: - Global "5 Finger Tap" with no modifiers -> "Enter Fullscreen (If Supported)" - Global "3 Finger Click" with no modifiers -> "Middle Click" If those are firing accidentally, identify them in the live config and tell me whether they should be disabled, remapped, or otherwise adjusted. ### Assistant I’m checking the live BetterTouchTool state directly in `~/Library/Application Support/BetterTouchTool`, then I’ll trace the active global and Obsidian-specific swipe gestures, confirm whether the duplicate `4 Finger Swipe Down` bindings are live, and only then make the smallest safe change. ### Assistant I’ve started with the live data store and nearby support files so we’re not accidentally reasoning from an export. Next I’m pulling the actual gesture records and log locations out of the live database before touching anything. ### Assistant The live store on this machine is not the `6_311` file you saw elsewhere; the active-looking candidate here is `btt_data_store.version_6_286_build_2026031912` with fresh `-wal` activity today, so I’m treating that as authoritative unless the running process points somewhere else. I’m checking the running BTT process, the database schema, and the recent log for gesture-loading clues now. ### Assistant The log already shows one likely accidental trigger: at `2026-04-20 16:13:52` BTT performed `Enter Fullscreen (If Supported)` via UUID `345FFA55-76D1-4A76-BBB4-8C0B2224E2BB`, so I’m mapping that UUID back to the live gesture record now. I’m also extracting the global and Obsidian app gesture containers directly from the database to verify the two `4 Finger Swipe Down` actions before editing anything. ### Assistant I’ve confirmed the log UUID belongs to a live entity in the database, but it’s one of BTT’s linked action records rather than a top-level named row, so I’m following the app-to-gesture relationships directly now. The next pass is a joined view of `Global` and `Obsidian` gesture trees with timestamps, modifiers, gesture types, and linked actions so we can distinguish the older `Cmd+M` swipe from the newer `Cmd+W` one safely. ### Assistant I’ve got the gesture/action rows now. One of the suspicious `Cmd+W` actions is clearly a child action row under gesture `996`, and the fullscreen action is a child action under gesture `993`; the remaining step is to resolve which parent gestures belong to `Global` versus `Obsidian` so we only disable the exact global duplicate. ### Assistant There are multiple live `Global` and `Obsidian` app containers in the database, not just one. I’m isolating which of those containers still have active gesture rows attached, because the duplicate behavior can come either from duplicate gestures inside one container or from multiple active global containers layered together. ### Assistant The duplicate-close hypothesis is taking shape cleanly now: `Cmd+M` and `Cmd+W` are both represented as child action rows under different top-level swipe gestures, and I’m resolving which parent gesture is global versus Obsidian before I flip anything. I’m also decoding the false-positive candidates the same way, using the log’s fullscreen UUID and the corresponding parent gesture type in the live DB. ### Assistant I’ve now confirmed there is only one active `Global` container with attached gestures on this machine, and the no-modifier `Cmd+W` swipe I found lives under app-specific containers, not under `Global`. I’m pulling every global no-modifier gesture that resolves to a mouse-style action next so I can pin down the suspected accidental `3 Finger Click -> Middle Click` entry before deciding whether to change anything. ### Assistant I’ve confirmed the exact live fullscreen trigger chain: `Global` parent `993` with no modifiers is active and resolves to action UUID `345FFA55-76D1-4A76-BBB4-8C0B2224E2BB`. I’m doing one last local lookup inside the BetterTouchTool app bundle for gesture-type labels so I can tell you, with fewer guesses, which of the remaining no-modifier mouse-style globals is the suspected `3 Finger Click`. ### Assistant The trigger-type map from the installed BTT bundle changed the picture: `4 Finger Swipe Down` is trigger type `124`, `5 Finger Tap` is `119`, and `3 Finger Click` is `111`. That means the `Cmd+M` and `Cmd+W` rows I first chased are not the swipe-down gesture you suspected, so I’m re-running the final checks against the correct live trigger IDs before I touch anything. ### Assistant The live config is clearer now: there is no active `5 Finger Tap` trigger at all, and there is no live no-modifier `3 Finger Click -> Middle Click` pair either. What does exist is a nearby no-modifier `Global 3 Finger Swipe Up -> Middle Click`, so I’m checking the log for any recent `performing 1` events to see whether that one has actually been firing. ### Assistant I inspected the live BetterTouchTool state on this Mac, not an export. The authoritative live store here is [btt_data_store.version_6_286_build_2026031912](/Users/nickyoung/Library/Application%20Support/BetterTouchTool/btt_data_store.version_6_286_build_2026031912), not the `6_311` file from the other machine. The current log at [com.hegenberg.BetterTouchTool 2026-04-20--13-56-44-859.log](/Users/nickyoung/Library/Application%20Support/BetterTouchTool/Logs/com.hegenberg.BetterTouchTool%202026-04-20--13-56-44-859.log) confirms that exact path on April 20, 2026 at `15:56:45`. What I found: - There is only one active `Global` container with attached gestures (`Z_PK 251`) and one active `Obsidian` container (`Z_PK 63`). Older `Global`/`Obsidian` rows exist in the DB, but they have no attached live gesture rows, so I did not find duplicate active Global containers. - `4 Finger Swipe Down` is trigger type `124` in this BTT build. In the live DB, there is no no-modifier Global `4 Finger Swipe Down` at all. - The only live `4 Finger Swipe Down` rows are: - `Global` parent `1178`, modifiers `786432`, disabled - `Obsidian` parent `1023`, modifiers `786432`, enabled - So there are not two no-modifier Global `4 Finger Swipe Down` gestures, and there is no live Global `4 Finger Swipe Down -> Cmd+M` plus Global `4 Finger Swipe Down -> Cmd+W` pair to disable. I made no config change, so I did not restart BTT. The false-positive check turned up something different: - There is no active `Global 5 Finger Tap` in the live config. `5 Finger Tap` is trigger type `119`, and there are no live rows for it. - The fullscreen trigger that is firing accidentally is actually `Global 3 Finger Click` with no modifiers: parent `993` (`ZGESTURETYPE 111`) -> child `981` (`ZACTION 112`, UUID `345FFA55-76D1-4A76-BBB4-8C0B2224E2BB`). The log shows it fired twice today: `2026-04-20 16:13:52` and `2026-04-20 16:51:53`. - There is no live `Global 3 Finger Click -> Middle Click`. The closest live match is `Global 3 Finger Swipe Up` with no modifiers: parent `1253` (`ZGESTURETYPE 112`) -> child `1254` (`ZACTION 1`, Middle Click). I did not see recent log hits for that one. My recommendation: - Disable the live `Global 3 Finger Click -> Enter Fullscreen` trigger. It is definitely active and definitely misfiring. - Leave the `Middle Click` mapping alone unless you’ve felt accidental `3 Finger Swipe Up` activations too; if so, disable or add a modifier. - There is nothing to disable for the specific `4 Finger Swipe Down` duplicate you described on the other machine, because that duplicate is not present here. If you want, I can disable the accidental `Global 3 Finger Click -> Enter Fullscreen` now and restart BetterTouchTool afterward. *Il vero problema qui non è il gesto a cinque dita, ma il clic a tre dita globale che entra in fullscreen per errore.* ### User "If you want, I can disable the accidental Global 3 Finger Click -> Enter Fullscreen now and restart BetterTouchTool afterward. Il vero problema qui non è il gesto a cinque dita, ma il clic a tre dita globale che entra in fullscreen per errore." please do ### Assistant I’m disabling the confirmed live fullscreen trigger in the database itself, with a timestamped backup first, then I’ll relaunch BetterTouchTool and verify the trigger is now marked disabled in the live store. ### Assistant I’ve re-confirmed the exact live row: parent `993`, no modifiers, enabled, with child action UUID `345FFA55-76D1-4A76-BBB4-8C0B2224E2BB`. Next I’m backing up the live store, stopping BTT, flipping that parent trigger to the same disabled state pattern used elsewhere in this database, and then relaunching. ### Assistant BTT is stopped and the live database is backed up. I’m applying the smallest change now: disabling only parent trigger `993`, which is the no-modifier `Global 3 Finger Click -> Enter Fullscreen` row that matched the log UUID.