Investigate Codex hardware / Work Louder control surface support on Linux

[joshyorko]

Summary

OpenAI Developers teased a Codex-related hardware release for July 15 with the line:

Your favorite Codex shortcuts are getting an upgrade.

The teaser appears to be an OpenAI × Work Louder device, likely a programmable macro/control surface rather than a new model or general-purpose AI device.

Source:

• https://www.theverge.com/ai-artificial-intelligence/959174/openai-codex-hardware-work-louder

This issue is not about tracking every hardware accessory. It is about tracking whether this launch reveals a first-party Codex desktop control-surface contract that codex-desktop-linux should support.

Why this matters for Linux

Most of the new Codex desktop primitives are currently macOS-first because OpenAI appears to be building and dogfooding there first:

• Record & Replay
• Computer Use helpers
• desktop plugin shells
• shortcut/control affordances
• app-specific workflow surfaces

That does not necessarily mean the underlying product contract is macOS-only. It may simply mean the first official helper implementation is macOS-only. Linux can often implement the same contract with different lower-level primitives.

For this hardware teaser, the important question is:

Is this just a macro pad sending keyboard shortcuts, or does the Codex desktop app expose a deeper shortcut/action/control protocol?

If it is only HID keyboard/macro behavior, Linux support may be mostly documentation, keymap profiles, and action mapping.

If it talks to the Codex desktop app through a local protocol, plugin hook, SDK surface, WebSocket, IPC, HID vendor protocol, or app action registry, then codex-desktop-linux should investigate implementing the same contract.

Hypothesis

This may be a Work Louder-style programmable control surface for Codex, potentially exposing buttons/actions for first-party Codex workflows such as:

• start/stop Record & Replay
• mark a recording step
• launch Skills / Plugins
• accept or reject patches
• run tests
• switch threads / goals / repositories
• stop/cancel an active task
• push-to-talk or voice context
• open terminal/browser/computer-use affordances

The launch may also reveal which Codex actions OpenAI considers flagship workflows. Record & Replay is especially likely to be part of the shortcut surface.

Investigation plan

Before July 15

Inspect the current Codex desktop app plumbing for signs that a shortcut/control-surface contract already exists:

• action registries or command palettes
• shortcut maps / keybinding maps
• global shortcut registration
• plugin action hooks
• Record & Replay activation hooks
• thread/goal start-stop action names
• app IPC routes for shortcut-triggered actions
• local WebSocket / RPC / MCP / helper process endpoints
• feature flags for hardware, shortcuts, Work Louder, HID, macro pad, control surface, or device integrations
• references in the app bundle to Work Louder, device IDs, or shortcut upgrade messaging

On / after July 15

Inspect the released artifact and app update:

• Does the device behave as plain HID keyboard input?
• Does Work Louder ship a keymap/profile only?
• Does Codex Desktop expose a device-specific protocol?
• Are new app APIs or plugin actions documented?
• Does the macOS app add a helper process similar to SkyComputerUseClient / Record & Replay?
• Are there new bundled plugins, MCP servers, action schemas, or shortcut metadata?
• Is there a platform gate that only blocks macOS implementation, or is the product contract itself macOS-only?

Linux implementation lanes

Depending on what the release reveals:

1. Plain macro pad lane

   • Document recommended Linux keybindings.
   • Provide importable Work Louder/QMK/VIA-style mappings if applicable.
   • Ensure Codex Linux exposes stable shortcuts for the same actions.

2. Codex action-registry lane

   • Implement the same app action names on Linux.
   • Add bridge methods where missing.
   • Make actions callable by keyboard, HID, plugin, and CLI where possible.

3. Device/protocol lane

   • Investigate udev/HID support if the hardware sends non-keyboard events.
   • Add Linux permission guidance if needed.
   • Avoid hardcoding a single device if a generic control-surface abstraction is possible.

4. Plugin/Skill lane

   • If the hardware is really a launcher for flagship plugin actions, ensure Linux plugin implementations expose the same actions.
   • Record & Replay should map to Linux event-stream/SkyLinuxComputerUseClient where available.

Non-goals

• Do not vendor proprietary OpenAI/Work Louder assets.
• Do not fake support for a hardware protocol until the contract is known.
• Do not make this dependent on owning the device if app-bundle/API inspection is enough to implement the software side.
• Do not build a generic macro-pad manager unless the Codex app contract requires it.

Desired outcome

A short research note or implementation PR that answers:

• What exactly did OpenAI ship on July 15?
• What Codex actions does the hardware control?
• Is it plain shortcuts, an app protocol, a plugin action surface, or a device-specific integration?
• What is already present in the Codex desktop app bundle?
• What must codex-desktop-linux implement so Linux users get equivalent behavior?

If there is a real app-level contract, the preferred long-term shape is:

Codex Linux exposes the same action/control surface as macOS, backed by Linux-native helpers and plugins, with hardware treated as one client of that surface rather than the whole feature.

[Yo-DDV]

Hi, thanks for opening this. One detail from the current desktop bundle helps make the scope more concrete.

In openai-codex-electron, @worklouder/device-kit-oai and @worklouder/wl-device-kit are already listed as dependencies. The bundle also includes a codex-micro-service that imports that kit and looks for DeviceType.Project2077.

That service forwards device state, HID events, and joystick movement into the primary Codex window. On the renderer side, there are also codex-micro-* paths for push-to-talk, inserting text into the composer, and inserting a skill mention.

So I think the issue can be tracked in a fairly concrete way:

• confirm the public product contract when it exists;
• map the Codex Micro surface already present in the bundle;
• check what the Linux build needs for native HID access and permissions.

The Linux-specific bit I verified today is that the kit loads with the real app.asar + app.asar.unpacked layout, but HID discovery stops because node-hid looks for a Linux binding that is not there:

HID_hidraw-linux-x64/node-napi-v4.node

That leaves a smaller set of checks for the port:

• does Codex Micro always go through this HID path on Linux?
• should the Linux build rebuild or stage that binding?
• do we need udev/hidraw guidance for device access?
• should this stay behind an opt-in feature while the product behavior settles?

That seems enough to move this from a broad watch item to a concrete Linux compatibility track.

[joshyorko]

@Yo-DDV thank you for this, im going to hold a few more days and tighten up SkySight and Record and Play then circle back to this.

[joshyorko]

https://www.youtube.com/watch?v=m8uUUUsMD3Y&pp=ygUSb3BlbmFpIHdvcmsgbG91ZGVy @Yo-DDV ITS HERE

[Yo-DDV]

https://www.youtube.com/watch?v=m8uUUUsMD3Y&pp=ygUSb3BlbmFpIHdvcmsgbG91ZGVy @Yo-DDV ITS HERE

Wwwwwwtttttfffffffffff man 😂