The Clawd Grip: breaking free from Logitech G HUB

12 Jul 2026

How Claude extended an open-source configuration tool to support my mouse, helped me dump and migrate my button bindings, and made a battery-status widget.

My favorite mouse is the Logitech G502, as well as its successors. It fits my hand, the build quality is excellent, and more than anything it has a lot of buttons that I have painstakingly customized. Clicking the wheel closes a browser tab, so a thumb button takes over as the real middle-click. Two other thumb buttons switch to the next and previous tab, and the two under my index finger go back and forward: page history in a browser, or the cursor position history in my code editor. I also love the free-spinning scroll wheel: flip a switch and it spins with almost no friction, so a single flick flies through a long file.

There are a few things I don’t like, though.

The first is connectivity. No G502 has Bluetooth, not even the wireless Lightspeed models, so the USB-A dongle comes with me everywhere, along with a USB-C to USB-A adapter for my laptop. The wireless version is especially unforgiving about this. Plug in a stray USB-C cable and it will charge the mouse but often send no input at all, because plenty of cables carry power but no data. It does work wired over a proper data cable, but the practical upshot is the same: to actually use the mouse you need either the dongle or a specific cable. At least the newer G502 X charges over USB-C, instead of the previous generation’s archaic micro-USB.

But my real problem is the software.

The problem with G HUB

To customize the mouse you are supposed to use Logitech G HUB, and G HUB is not good. It is bloated and slow, it nudges you to create an account, and everything has to be set up by hand through the GUI. There is no clean way to export your configuration to a file and version it. It occasionally crashes. These are not just my personal grievances: the Consumer Rights Wiki documents the account pressure and bloat, and it is a perennial complaint online. And of course there is no official Linux support, which the community has had to work around with projects like Solaar and Piper.

For all these reasons, I stopped depending on G HUB and moved my setup onto the mouse itself.

Onboard memory + Karabiner

Logitech mice have onboard memory: a small flash chip that stores profiles (DPI steps, polling rate, and button assignments) directly on the device. Once a profile is written, it works on any computer, with no software and no account, because the mouse is doing the remapping in its own firmware.

My trick is to map the extra buttons to function keys (F13 through F24, which no application uses) and then translate those into real shortcuts with Karabiner-Elements, whose configuration is a plain text file I can edit and commit. So the mouse emits F22 and Karabiner turns it into ⌘W:

"from": { "key_code": "f22" },<br>"to": [{ "key_code": "w", "modifiers": ["left_command"] }],<br>"type": "basic"

The heavy customization lives in one JSON file, and the mouse itself only ever sends boring function keys. I like this a lot.

Migrating to a new mouse

The catch: writing those onboard profiles still meant using G HUB once. And when I bought the newer G502 X, I wanted to migrate my configuration over without having to painfully set each keybinding in G HUB.

That is how I found opengcontrol, an open-source command-line alternative to G HUB written in Rust. It talks to the mouse directly over HID++ 2.0, Logitech’s feature-based control protocol layered on top of plain USB HID, with no background daemon and no account. From the terminal you can read and change the DPI steps and polling rate, inspect and remap buttons, list and switch the onboard profiles, and read the battery. There is no GUI, but there is a genuinely nice TUI dashboard that shows every setting at once, and since all of it is scriptable, it can just as easily be driven by an agent.

There was one problem: it did not support my devices, and it was missing most of the features I needed. So I sat down with Claude Code and, with surprisingly little intervention, we added them. In a single pull request:

device definitions for the G502 LIGHTSPEED and the G502 X LIGHTSPEED;

reading and writing onboard profiles for the “sector-addressed” memory layout these mice use, including the CRC the firmware expects (get that wrong and the write is rejected);

profile clone, which copies a profile from one mouse onto another and automatically remaps the buttons , because the two G502 models number their physical buttons differently (a naive byte copy scrambled which physical button did what: tilting the wheel suddenly fired keystrokes);

battery readout over HID++, with a voltage-curve estimate for the older mouse, which predates the modern battery feature;

a fix for setting the polling rate on mice in onboard mode, where the rate is stored in the profile rather than set live.

Claude also chased down a...