Input Monitoring permission and Suppression support #3098

New issue

Open

opened 2026-02-20 22:18:01 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-20 22:18:01 -05:00

Owner

Originally created by @nicholas-lonsinger on GitHub (Feb 1, 2026).

Context

I see that this has been talked about many times including recently and I am not trying to beat a dead horse here.

Now that the current master branch targets 10.15 of macOS, the Input Monitoring permission level for Push To Talk can be used (it was introduced in 10.15) rather than the much broader Accessibility Settings. Making this switch though would lead to the loss of Suppression support which may be acceptable considering it is not available on Windows/Linux from what I have read.

Here is a branch that currently works with Input Monitoring: https://github.com/nicholas-lonsinger/mumble/tree/input-monitoring I have left much of the code as is (left in Suppression support as well as other checks no longer needed, code paths no longer hit, UI no longer displayed, docs/screenshot), so that I could minimize the changes and get feedback before making a more complete change/PR.

A couple options:

Submit the PR as is, leaving the Suppression code in place. Follow this with a second PR to remove dead/unused code paths and UI. Possibly a third PR to move the Input Monitoring prompt to only when needed/used rather than at launch.
Combine the PRs above (or split out just the third)
Improve the patch to include support for Suppression. This can be done through privilege escalation, where when setting up Global Shortcuts Input Monitoring is used (and required to be granted by the user), and only when the user enables Suppression would the user need to grant the accessibility permission.

For the third PR mentioned above: I would also suggest moving the request for Input Monitoring permissions to the point when the user enables Global Shortcuts (probably after it is saved when the user hits OK, rather than right when the checkbox is checked). I could either add that to in this patch or a subsequent one to keep the changes as small as possible per patch.

From my research it looks like Suppression support can exist on Windows as well (SetWindowsHookEx(WH_KEYBOARD_LL, ...) a different implementation, and may have some conflicts with anti-cheat software. But you may want to be going towards more broad support for Suppression rather than less.

Since suppression is not used today for the majority of the softwares users (on Windows/Linux), I would say the cleanest option is to bring macOS to parity with those other builds while at the same time reducing permissions needed and cleaning up / reducing the code base as well.

I'd love to get your feedback here and then submit a PR.

Sorry this was so long, it feels complicated and I wanted to give enough background as it has already gone back and forth a few times in other threads.

Description

Remove Accessibility permission requirement and move to using only Input Monitoring on macOS.

Additionally delay the prompt for Input monitoring to the first time it is used/needed. Either when the program launches and sees the setting is already configured; or once the user configures the setting and hits apply/OK in the settings window.

Lastly on macOS, when you make the permission change it will offer to close / relaunch the application to have the setting take effect, but this does not always work due to different modal windows block it. It would be ideal to have this work and then bring you right back to where you were. For me the app launches with the connection modal up, but this may also apply to the settings window being open.

Mumble component

Client

OS-specific?

Yes

Additional information

No response

Originally created by @nicholas-lonsinger on GitHub (Feb 1, 2026). ### Context I see that this has been talked about many times including recently and I am not trying to beat a dead horse here. Now that the current master branch targets 10.15 of macOS, the Input Monitoring permission level for Push To Talk can be used (it was introduced in 10.15) rather than the **much** broader Accessibility Settings. Making this switch though would lead to the loss of Suppression support which may be acceptable considering it is not available on Windows/Linux from what I have read. Here is a branch that currently works with Input Monitoring: https://github.com/nicholas-lonsinger/mumble/tree/input-monitoring I have left much of the code as is (left in Suppression support as well as other checks no longer needed, code paths no longer hit, UI no longer displayed, docs/screenshot), so that I could minimize the changes and get feedback before making a more complete change/PR. A couple options: - Submit the PR as is, leaving the Suppression code in place. Follow this with a second PR to remove dead/unused code paths and UI. Possibly a third PR to move the Input Monitoring prompt to only when needed/used rather than at launch. - Combine the PRs above (or split out just the third) - Improve the patch to include support for Suppression. This can be done through privilege escalation, where when setting up Global Shortcuts Input Monitoring is used (and required to be granted by the user), and only when the user enables Suppression would the user need to grant the accessibility permission. For the third PR mentioned above: I would also suggest moving the request for Input Monitoring permissions to the point when the user enables Global Shortcuts (probably after it is saved when the user hits OK, rather than right when the checkbox is checked). I could either add that to in this patch or a subsequent one to keep the changes as small as possible per patch. From my research it looks like Suppression support can exist on Windows as well (SetWindowsHookEx(WH_KEYBOARD_LL, ...) a different implementation, and may have some conflicts with anti-cheat software. But you may want to be going towards more broad support for Suppression rather than less. Since suppression is not used today for the majority of the softwares users (on Windows/Linux), I would say the cleanest option is to bring macOS to parity with those other builds while at the same time reducing permissions needed and cleaning up / reducing the code base as well. I'd love to get your feedback here and then submit a PR. Sorry this was so long, it feels complicated and I wanted to give enough background as it has already gone back and forth a few times in other threads. ### Description Remove Accessibility permission requirement and move to using only Input Monitoring on macOS. Additionally delay the prompt for Input monitoring to the first time it is used/needed. Either when the program launches and sees the setting is already configured; or once the user configures the setting and hits apply/OK in the settings window. Lastly on macOS, when you make the permission change it will offer to close / relaunch the application to have the setting take effect, but this does not always work due to different modal windows block it. It would be ideal to have this work and then bring you right back to where you were. For me the app launches with the connection modal up, but this may also apply to the settings window being open. ### Mumble component Client ### OS-specific? Yes ### Additional information _No response_