[Bug]: macOS — granting Input Monitoring has no effect until the agent's launchd job is restarted, so "Try again" can never succeed #1304

Pre-flight checklist

• I searched existing issues and this is not a duplicate. (This may well be the root cause behind [Bug]: Permissions - Input monitoring #1261 and [Bug]: Mac Brew Installation apparently cannot get Input Monitoring permission #1135 — both describe "permission is granted but OpenLogi says it isn't". Filing separately because I have the exact mechanism and a one-command fix; happy to have it merged into [Bug]: Permissions - Input monitoring #1261.)
• I am on the latest release or a recent master build.
• I quit Logi Options+ before running OpenLogi (never installed on this machine).

Which part of OpenLogi?

GUI (desktop app)

OpenLogi version

0.8.3 (build 20260830.162827), signed DMG install in /Applications

Operating system

macOS

OS version & architecture

macOS 26.5.2 (25F84), arm64 (Apple Silicon)

Device model

MX Mechanical Mini (keyboard) + MX Vertical (mouse)

How is the device connected?

Bluetooth (direct, no 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?

Summary: once openlogi-agent has been denied Input Monitoring, granting the permission has no effect until the launchd job is restarted — and nothing in OpenLogi ever restarts it. "Try again" retries inside the same process, so it can never succeed.

Add Device failed with:

HID transport error: Failed to open device: Input Monitoring is NOT granted to this process; grant it to OpenLogi Agent under System Settings → Privacy & Security → Input Monitoring

The permission was already granted. ~/.local/state/openlogi/agent.<date>.log shows the same error repeating every ~2 s for ~18 minutes while the toggle was on. Then, with zero changes to any permission:

launchctl kickstart -k gui/$(id -u)/org.openlogi.agent.service

and the agent opened the HID++ channel on the first attempt. Both devices appeared immediately, with battery levels.

Why this happens: on macOS the Input Monitoring (kTCCServiceListenEvent) decision is resolved for a process when it starts, and a running process does not pick up a grant made afterwards — the same reason System Settings tells apps to quit and reopen. openlogi-agent is a KeepAlive launchd job registered through SMAppService (parent bundle identifier = org.openlogi.openlogi), so:

• toggling the switch in System Settings does not restart it;
• quitting and reopening OpenLogi.app does not restart it either — launchd keeps the agent alive across GUI restarts;
• so the only exit from the bad state is a launchctl kickstart, a logout, or a reboot — none of which the app suggests.

Anyone who installs OpenLogi, hits the permission error, grants the permission, and clicks Try again is stuck in a loop that looks like the permission itself is broken.

Secondary problem — the error text sends users to a row that doesn't exist. It says to grant it to OpenLogi Agent, but on my machine Input Monitoring only ever lists a single row, OpenLogi (the parent bundle), and after the agent restart that single grant was enough to cover the helper. There is no separate "OpenLogi Agent" row to enable. That is exactly the dead end reported in #1261 ("I have even added OpenLogi agent to no success").

Steps to reproduce

1. Install 0.8.3 (signed DMG) on macOS 26, launch it, let the login-item agent start. Do not grant Input Monitoring yet.
2. Open Add Device → "Pairing failed", with the Input Monitoring message. The agent log starts repeating the error every ~2 s.
3. Go to System Settings → Privacy & Security → Input Monitoring and enable OpenLogi. Leave the app and the agent running (this is what a user naturally does — the toggle is presented as the fix).
4. Click Try again → same failure. Quitting and reopening OpenLogi.app also does not help, because the agent is a separate launchd job that survives.
5. Run launchctl kickstart -k gui/$(id -u)/org.openlogi.agent.service → devices are detected instantly, no permission changes needed.

Suggested fix

• When a HID open fails with a TCC denial, have the GUI (or the agent itself) restart the launchd job rather than retrying in-process — e.g. wire Try again and the Permissions pane's Input Monitoring row to a kickstart / SMAppService re-register, or have the agent re-exec itself once it observes IOHIDCheckAccess flip to granted.
• At minimum, change the copy to say the agent must be restarted after granting, and name the row users will actually see (OpenLogi, not "OpenLogi Agent"). The GUI already has a "Relaunch OpenLogi" affordance for updates; a "Restart agent" button here would remove the dead end entirely.

Diagnostics report

- OpenLogi (GUI): v0.8.3 (release, signed DMG)
- Agent: v0.8.3, launchd job org.openlogi.agent.service (SMAppService, KeepAlive, parent bundle org.openlogi.openlogi)
- OS: macOS 26.5.2 (25F84), arm64
- Accessibility: granted (agent logs "accessibility granted — installing OS mouse hook" on every start)
- Input Monitoring: granted — one row, "OpenLogi"; no "OpenLogi Agent" row is ever offered
- Code signature: Developer ID Application: AprilNEA LLC (8U3ZJ258K9), all three bundles
- Devices: MX Mechanical Mini + MX Vertical, both BLE-direct

openlogi list output

(inventory read from the running agent)
MX MCHNCL M (—, vid=046d pid=b367)
  └─ slot 255 ● MX Mechanical Mini (keyboard, wpid=?, battery=100% full (discharging))
          model_ids=[b367,0000,0000] ext=00 serial=<redacted> unit_id=341c5c6d transports=btle

MX Vertical (—, vid=046d pid=b020)
  └─ slot 255 ● MX Vertical Advanced Ergonomic Mouse (mouse, wpid=?, battery=90% full (discharging))
          model_ids=[b020,407b,c08a] ext=00 serial=— unit_id=417ddba9 transports=usb+equad+btle

(This is the state after the agent restart — before it, the inventory was empty.)

Logs

Agent process had been running since 23:57:54; the Input Monitoring toggle was switched on while it ran. ~/.local/state/openlogi/agent.<date>.log:

# ~18 minutes of this, every ~2 s, with the permission already granted:
00:02:44 WARN openlogi_device::inventory: failed to open HID++ channel — requesting repair error=Backend("Failed to open device: Input Monitoring is NOT granted to this process; grant it to OpenLogi Agent under System Settings → Privacy & Security → Input Monitoring")
...
00:15:55 WARN openlogi_device::inventory: failed to open HID++ channel — requesting repair error=Backend("Failed to open device: Input Monitoring is NOT granted to this process; ...")

# launchctl kickstart -k gui/501/org.openlogi.agent.service — no permission was changed:
00:15:50 INFO openlogi_agent::shutdown: releasing the input hook and exiting reason="shutdown signal"
00:15:50 INFO openlogi_agent::server: IPC server listening
00:15:50 INFO openlogi_agent::lifecycle: openlogi-agent started
00:15:50 INFO openlogi_agent::lifecycle: accessibility granted — installing OS mouse hook
00:15:51 INFO openlogi_agent_core::watchers::inventory: system resume — replaying settings on a settled inventory
00:15:55 INFO openlogi_device::session::gesture: control capture active index=255 ... dpi_buttons=1 ...

# zero occurrences of "Input Monitoring is NOT granted" after the restart

macOS permissions (if applicable)

Accessibility: granted. Input Monitoring: granted to OpenLogi (single row, parent bundle — it does cover the agent, but only from the agent's next launch onward).