WisperTalk 1.2.2

Fixed — "Accessibility is not enabled" even after you enabled it

1.2.1 asked macOS for the permission correctly, but two macOS behaviours make granting it impossible or ineffective — and the app gave no hint either was happening.

App Translocation. An app opened from the mounted disk image — or from Downloads while still quarantined — is run by macOS from a randomised, read-only location. Accessibility can never be granted in that state. The toggle can be switched on over and over and the app stays denied, with no explanation. WisperTalk now detects this and tells you to move it to Applications, instead of sending you to a toggle that cannot work.

Stale permission entries. macOS ties Accessibility to the app's code signature. Builds are now signed with a Developer ID, so a permission granted to an earlier unsigned build no longer applies — the old entry still shows as switched on while actually being denied. The dialog now tells you to remove the entry with the minus (−) button and add it again, because toggling it off and on often does not clear the old binding.

Already stuck? Fix an existing install

Quit WisperTalk, then in Terminal:

xattr -dr com.apple.quarantine /Applications/WisperTalk.app
tccutil reset Accessibility com.wispertalk.app

Then open it from Applications — not from the disk image — and allow Accessibility when asked.

First launch on macOS

Signed with a verified Apple Developer ID but not yet notarised, so macOS shows a warning offering the Trash. Click Done, then System Settings → Privacy & Security → Open Anyway. Once per machine.