[Bug]: Back and Forward Buttons not working

[8s8ybbf7mx-sys]

Pre-flight checklist

• I searched existing issues and this is not a duplicate.
• I am on the latest release or a recent master build.
• I quit Logi Options+ before running OpenLogi (the two apps fight over HID++ access and only one can own a receiver at a time).

Which part of OpenLogi?

GUI (desktop app)

OpenLogi version

0.6.18

Operating system

macOS

OS version & architecture

26.5.2, Apple Silicon

Device model

MX Master 3S + Bolt Receiver

How is the device connected?

Logi Bolt receiver

Affected area(s)

• Device discovery / detection
• Button remapping
• DPI control
• SmartShift
• Per-application profiles
• Battery status
• Settings / configuration (TOML)
• Auto-update
• Menu bar / tray
• Other

What happened?

Pre-flight checklist

• I searched existing issues and this is not a duplicate.
• I am on the latest release (v0.6.18).
• I quit Logi Options+ before running OpenLogi (fully uninstalled, no background process remaining).
• OpenLogi has Accessibility permission (Settings → Permissions shows "Erteilt"/Granted).
• OpenLogi has Input Monitoring permission (Settings → Permissions shows "Erteilt"/Granted).

Bug description

The Back and Forward side buttons on an MX Master 3S do not trigger any action, even when bound to MouseBack / MouseForward ("the real extra-button events most apps treat as native back/forward" per the docs). No reaction in Safari, and also no reaction in Finder (which natively responds to real mouse buttons 3/4 for folder navigation) — so this doesn't appear to be app-specific.

Steps to reproduce

1. Connect an MX Master 3S via Logi Bolt receiver.
2. In OpenLogi, bind Back → MouseBack and Forward → MouseForward.
3. Click a link in Safari, then press the Back button on the mouse.
4. Navigate into a subfolder in Finder, then press the Back button on the mouse.

Diagnostics report

### OpenLogi Diagnostics

**App**
- OpenLogi (GUI): v0.6.18 (release)
- Agent: v0.6.18 (connected)
- IPC protocol: GUI 8 / agent 8
- Inventory: ready
- OS: macOS 26.5.2 (arm64)
- Locale: de-DE (UI: en)
- Accessibility: granted · Input hook: installed
- Launch at login: yes · Menu bar: yes · Update check: on
- Running from: source build (dev)
- Config: schema 3 · 1 configured device(s) · thumbwheel 14

**Assets**
- Source: user cache · Index: loaded (210 models) · User cache: present
- Cache path: ~/.local/share/openlogi/assets · Bundle assets: absent

**Devices (2)**
- MX Master 3S — mouse (codename: MX Master 3S )
  - Connection: Logi Bolt receiver · Online: no · Battery: 30% (discharging, low)
  - Capabilities: buttons=yes, pointer=yes, lighting=no
  - Model: receiver:417424e1a0e4b5d7:slot:1 (model-ids: b034/0000/0000, ext-model: 03)
  - Transports: BTLE
  - Render: mx_master_3s · Slot 1
- MX Master 3S — mouse (codename: MX Master 3S )
  - Connection: Logi Bolt receiver · Online: yes · Battery: 30% (discharging, low)
  - Capabilities: buttons=yes, pointer=yes, lighting=no
  - Model: receiver:417424e1a0e4b5d7:slot:2 (model-ids: b034/0000/0000, ext-model: 03)
  - Transports: BTLE
  - Render: mx_master_3s · Slot 2

**Receivers (1)**
- Logi Bolt Receiver (VID 046d / PID c548)

openlogi list output

Logs

macOS permissions (if applicable)

• OpenLogi has Accessibility permission (needed to remap buttons via the event tap).
• OpenLogi has Input Monitoring permission (needed for Bluetooth-direct devices and capture).

[linear-code]

OLG-123

[8s8ybbf7mx-sys]

Expected behavior

Safari/Finder navigate back/forward, as described in the docs for the MouseBack/MouseForward actions.

Actual behavior

Nothing happens in either app, in either direction.

Additional context

• Initially bound Back/Forward to BrowserBack/BrowserForward. In that configuration, Forward triggered the macOS "Zoom In" shortcut (Cmd+Plus) instead of browser navigation, and Back did nothing.
• Switched to MouseBack/MouseForward (both in the GUI and by hand-editing config.toml while the app was fully quit) — no change in behavior.
• Config persists correctly across app restarts (flat Back = "MouseBack" / Forward = "MouseForward" form, not reverted to a per-direction gesture table).
• Also noticed: an initial config revision was missing the Back binding entirely after setting it via the GUI action picker (only Forward = "BrowserForward" was written) — possibly a separate/related GUI save bug.

Config (relevant excerpt)

schema_version = 3
selected_device = "receiver:417424e1a0e4b5d7:slot:2"

[devices."receiver:417424e1a0e4b5d7:slot:2".identity]
display_name = "MX Master 3S"
codename = "MX Master 3S "
kind = "mouse"

[devices."receiver:417424e1a0e4b5d7:slot:2".identity.model_info.transports]
usb = false
equad = false
btle = true
bluetooth = false

[devices."receiver:417424e1a0e4b5d7:slot:2".bindings]
Back = "MouseBack"
Forward = "MouseForward"

Environment

• OpenLogi (GUI): v0.6.18 (release)
• OS: macOS [bitte genaue Version eintragen, z. B. via → Über diesen Mac], Apple Silicon (M3 Pro)
• Device: MX Master 3S, connected via Logi Bolt receiver
• Accessibility: granted · Input Monitoring: granted

[knispo]

Happening for me as well for about two days now I'd say.

[b0x42]

Experiencing the same issue with an MX Vertical (direct USB/eQuad connection). Back button does nothing even when bound to BrowserBack.

Relevant config excerpt (~/.config/openlogi/config.toml):

schema_version = 3
selected_device = "direct:046d:b020:unit:XXXXXXXX"

[devices."direct:046d:b020:unit:XXXXXXXX".identity]
display_name = "MX Vertical"
codename = "MX Vertical"
kind = "mouse"

[devices."direct:046d:b020:unit:XXXXXXXX".identity.model_info.transports]
usb = true
equad = true
btle = true
bluetooth = false

[devices."direct:046d:b020:unit:XXXXXXXX".identity.capabilities]
buttons = true
pointer = true
lighting = false
scroll_inversion = false

OpenLogi Diagnostics

App

• OpenLogi (GUI): v0.6.18 (release)
• Agent: v0.6.18 (connected)
• IPC protocol: GUI 8 / agent 8
• Inventory: ready
• OS: macOS 26.5.2 (arm64)
• Locale: en-GB (UI: follow system)
• Accessibility: granted · Input hook: installed
• Launch at login: yes · Menu bar: no · Update check: off
• Running from: source build (dev)
• Config: schema 3 · 3 configured device(s) · thumbwheel 14

Assets

• Source: user cache · Index: loaded (210 models) · User cache: present
• Cache path: ~/.local/share/openlogi/assets · Bundle assets: absent

Devices (2)

• MX Vertical — mouse (codename: MX Vertical)
  • Connection: Bluetooth (direct) · Online: yes · Battery: n/a
  • Capabilities: buttons=yes, pointer=yes, lighting=no
  • DPI: 1000 dpi (range 400–4000, 37 steps)
  • Model: direct:046d:b020:unit:XXXXXXXX (model-ids: b020/407b/c08a, ext-model: 00)
  • Transports: USB, eQuad, BTLE
  • Render: mx_vertical · direct
• MX Vertical — mouse
  • Connection: unknown · Online: no · Battery: n/a
  • Capabilities: buttons=yes, pointer=yes, lighting=no
  • Model: direct:046d:b020:unit:00000000
  • Render: ⚠️ none (silhouette) · Slot 0

[b0x42]

Fixed in draft PR #363: #363

The root cause: the MX Vertical reports Back/Forward via HID++ CIDs (0x0053/0x0056) rather than standard OS mouse button events, so OpenLogi's CGEventTap hook never saw them. Additionally, Safari's WKWebView ignores synthetic CGEvents entirely.

The fix captures the buttons via HID++ diversion and uses the Accessibility API (AXPress on Safari's toolbar button) for Safari, falling back to Cmd+[/Cmd+] for Chrome and other browsers. Tested on MX Vertical over Bluetooth — both Safari and Chrome work.