BTT: `get_string_variable` crashes BetterTouchTool when the name exists only as a number variable

mrwildenfree · August 9, 2026, 8:54am

Version: BetterTouchTool 6.706 (build 2026080706)

macOS: 27.0 beta (26A5388g), Apple M3 Max

Summary

Calling the AppleScript command get_string_variable with a variable name that exists only in BTT's number namespace raises an uncaught Objective-C exception inside BTT's own AppleEvent handler, which aborts the process. BetterTouchTool dies and relaunches.

This is fully deterministic — reproduced 17 times out of 17 attempts.

Steps to reproduce

Set a number variable, e.g. via AppleScript or any BTT action: set_number_variable "myvar" to 1
Ask for the same name as a string:applescript tell application "BetterTouchTool" to get_string_variable "myvar"
BetterTouchTool aborts immediately and relaunches.

The reverse direction is safe: get_number_variable on a string variable returns normally. Only the string getter crashes.

Expected

Return an empty result, an "unset" indication, or a normal AppleScript error. A type mismatch on a read-only getter should not terminate the application.

missing value would be the consistent answer here: in [thread 39031](https://community.folivora.ai/t/created-named-trigger-variable-but-get-string-variable-fai led-as-trigger-not-active/39031) get_string_variable already returns missing value when the variable has not been set, and that is confirmed there as intended behaviour. So the graceful path exists — the number-namespace case simply is not routed through it.

Checked for duplicates

I looked for existing reports before posting. The two closest threads describe different problems, neither involving a crash:

[42424](https://community.folivora.ai/t/get-string-variable-variable-name-selected-text-copies-the-text -to-the-clipboard/42424/3) — get_string_variable on the dynamic selected_text variable modifies the clipboard. A pasteboard side effect inherent to how that variable is captured, not an abort.
[39031](https://community.folivora.ai/t/created-named-trigger-variable-but-get-string-variable-failed-a s-trigger-not-active/39031) — returns missing value for a named-trigger variable whose trigger had never executed. Resolved, and correct behaviour.

Neither mentions an uncaught exception, SIGABRT, BTT relaunching, or the -609 that surfaces to the caller. If I have missed an existing report, point me at it and I will add my reproduction there instead.

Actual

SIGABRT. Crash stack: _NSAppleEventManagerGenericHandler → BetterTouchTool → objc_exception_throw → abort

Why this matters beyond the obvious

Any tool that enumerates BTT variables generically — a scripting bridge, an automation layer, a status widget polling values — will hit this the moment a caller does not already know a variable's type. There is no way to ask the type first, so the safe order has to be discovered by crashing the app.

It is also easy to make far worse by accident: a client that treats the resulting failure as a transient AppleEvent error (-609 "connection is invalid" is what surfaces to the caller) and retries will kill BTT once per retry. We did exactly that before diagnosing it, and killed BTT three times per call.

Workaround currently in use

Always probe get_number_variable first and only issue get_string_variable once the number probe reports unset. Verified safe in both directions.

Suggested fix

Wrap the string-variable lookup so a type mismatch returns a value or a normal scripting error instead of throwing past the AppleEvent handler. If practical, also expose the variable's type, so callers do not need to probe at all.