[Bug] Desktop hijacks mouse XButton1/XButton2 with no opt-out — accidentally switches active chat during normal use

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code Desktop on Windows binds mouse buttons 4 and 5 (XButton1 / XButton2 — the side "back/forward" thumb buttons) to chat back/forward navigation. There is no way to disable or remap this. This is a UX/accessibility bug:

• Side mouse buttons are commonly used by users as a global hotkey (push-to-talk, voice dictation triggers, macros, accessibility tools). The moment they press their hotkey while Claude Code is focused, Claude silently switches to a different chat, losing context of what they were typing or about to dictate.
• The action is destructive — the user is now in the wrong chat — and there is no visual warning, no confirmation, no undo affordance beyond pressing forward and hoping it lands back.
• The binding is hidden: it doesn't appear in the keybindings UI, it isn't documented, and it isn't in settings.json. A user whose chat keeps disappearing has no obvious way to figure out why.

Severity for accessibility: any user who relies on a thumb-button trigger for assistive software (voice input, switch-control mappings) cannot use that workflow inside Claude Code without their chat jumping around under them.

A working app should let users rebind or unbind XButton1 / XButton2 the same way every other shortcut is configurable.

What Should Happen?

Mouse buttons 4 and 5 should be configurable in the keybindings system like every other shortcut — users should be able to:

• Remap them to a different action.
• Unbind them entirely so the OS / other apps receive the click.

Any one of these is enough to fix the UX bug:

1. Expose XButton1 / XButton2 in the keybindings UI / keybindings.json so they can be rebound or cleared (preferred — consistent with how every other shortcut works).
2. Settings toggle, e.g. "desktop.mouseNavigation": false in settings.json.
3. Don't swallow the event — at minimum, let the click propagate to OS-level hooks after the in-app handler runs, so global hotkeys still fire.

Expected outcome: a user can press their thumb button without losing their place in Claude Code.

Error Messages/Logs

(none — the bug is silent UI navigation, no errors or logs are produced)

Steps to Reproduce

1. Open Claude Code Desktop on Windows with a 5-button mouse.
2. Have multiple chats / sessions in the sidebar so there is somewhere to navigate to.
3. Open any chat and start typing.
4. Press mouse button 5 (the thumb "back" button) anywhere over the app window.

Observed: the active chat changes — the user is taken to the previous chat in history, mid-typing. No confirmation, no warning, no setting to prevent it.

Expected: the click either does nothing, or runs whatever the user has bound to that button (currently impossible because the binding is not exposed).

Note: this affects the global press of the button, not only clicks on the navigation arrows.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

v1.7196.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_