You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have read and understood the important section above.
I have searched existing issues and avoided creating duplicates.
I am not filing an enhancement request.
I have checked that this issue cannot be reproduced on Mozilla Firefox.
I have checked that this issue can be reproduced once I removed all my Mods and Custom CSS.
What happened?
On MacOS, it seems that keyboard bindings native to NSMenu — Cmd+P for Print, Cmd+F for Find, etc., cannot be remapped to no-op. When these shortcuts are removed from their native functions in Zen Settings, they will still continue to execute their native command until remapped to another command, and cannot be no-op'd entirely.
Expected behavior
Setting a MacOS native keybinding to Not set should disable it.
Actual behavior
The binding persists until explicitly remapped onto another command.
Steps to reproduce
For example, setting Print from the default Cmd+P to Not set will still activate the print dialog, and setting Find from Cmd+F to Not Set will still bring up Find on Page.
This also seems to happen when these native bindings are remapped, via Zen, to other bindings. For example, when setting Print to something like Cmd+Shift+/, leaving Cmd+P used by no other command, both the new macro and Cmd+P will bring up the print dialog. This behavior is also confirmed for Find.
What does resolve the issue is to set the native command to another binding. For example:
Set Print to Not Set
Remap Cmd+P to another command ("Toggle Floating Sidebar", for example)
Cmd+P will execute the other command, and not bring up the print dialog.
Screenshots and videos
Screen.Recording.2026-05-11.at.2.17.16.PM.mov
Demonstration of the issue on MacOS. Between each rebind, Cmd+P is pressed to demonstrate what action it's mapped to at the time. The only time Cmd+P doesn't invoke Print is when it's explicitly remapped to another command.
Screen.Recording.2026-05-11.at.2.20.07.PM.mov
Additional demonstration on the same Zen build on Arch Linux, demonstrating that this is not a universal issue.
Preliminary Checks
What happened?
On MacOS, it seems that keyboard bindings native to NSMenu —
Cmd+Pfor Print,Cmd+Ffor Find, etc., cannot be remapped to no-op. When these shortcuts are removed from their native functions in Zen Settings, they will still continue to execute their native command until remapped to another command, and cannot be no-op'd entirely.Expected behavior
Setting a MacOS native keybinding to
Not setshould disable it.Actual behavior
The binding persists until explicitly remapped onto another command.
Steps to reproduce
For example, setting Print from the default
Cmd+PtoNot setwill still activate the print dialog, and setting Find fromCmd+FtoNot Setwill still bring up Find on Page.This also seems to happen when these native bindings are remapped, via Zen, to other bindings. For example, when setting Print to something like
Cmd+Shift+/, leavingCmd+Pused by no other command, both the new macro andCmd+Pwill bring up the print dialog. This behavior is also confirmed for Find.What does resolve the issue is to set the native command to another binding. For example:
Not SetCmd+Pto another command ("Toggle Floating Sidebar", for example)Cmd+Pwill execute the other command, and not bring up the print dialog.Screenshots and videos
Screen.Recording.2026-05-11.at.2.17.16.PM.mov
Demonstration of the issue on MacOS. Between each rebind,
Cmd+Pis pressed to demonstrate what action it's mapped to at the time. The only timeCmd+Pdoesn't invoke Print is when it's explicitly remapped to another command.Screen.Recording.2026-05-11.at.2.20.07.PM.mov
Additional demonstration on the same Zen build on Arch Linux, demonstrating that this is not a universal issue.
Version
1.19.12b
What platform are you seeing the problem on?
macOS - aarch64
What component is this issue related to?
Keyboard Shortcuts
Relevant log output if applicable