Feature Request: Official Codex Desktop external control API for hardware controllers

Open 💬 3 comments Opened Jul 16, 2026 by ssm-0123
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App

What feature would you like to see?

Feature Request: Official Codex Desktop external control API for hardware controllers

I attempted to build a Stream Deck plugin for Codex Desktop that can control a live Codex task from hardware buttons: run a prompt, submit the current draft, stop a turn, show task status, and approve or reject permission requests.

With the currently public integration surfaces, this is difficult to implement reliably without private IPC reverse engineering, Windows UI Automation, or keyboard macros. Those approaches are fragile and not appropriate for security-sensitive actions like approving command execution.

The main blockers observed while developing the plugin were:

  • No stable documented local control API for Codex Desktop.
  • No first-class API for listing and responding to approval requests.
  • No documented task/approval event stream for reliable hardware status indicators.
  • No official way to discover the active Codex task.
  • No official way to submit the current composer draft without fake keyboard input.

The three P0 requests that would make a production-quality Stream Deck plugin possible are:

  1. Stable Local Control API
  2. Approval Request/Response API
  3. Task/Approval Event Stream

Codex Micro appears to highlight that hardware-assisted Codex workflows can be valuable. Without making assumptions about its implementation, similar workflows could be enabled for existing hardware such as Stream Deck, Loupedeck, QMK keyboards, and other local controllers if Codex Desktop exposed a stable, permissioned external-control API.

I have a longer RFC with concrete API examples, permission model suggestions, idempotency/audit-log requirements, and implementation pain points observed during development:

Full RFC with detailed API examples and implementation notes:
OPENAI_FEATURE_REQUEST.md

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33556
  • #33528

Powered by Codex Action

brandonsoccer22 · 19 days ago

Alongside a stable external-control API, it would be great if OpenAI could consider an official Stream Deck plugin for Codex Desktop. A first-party integration could make common task controls, status, and approval visibility accessible out of the box, while the API would still enable the broader hardware ecosystem.

roflsunriz · 9 days ago

I’d like to add another concrete use case for this request: expose the same class of controls that the ChatGPT/Codex desktop app already provides to Codex Micro / Creators Micro2 through a stable, public, well-documented local API, so users can build integrations for arbitrary macro keyboards and external controllers without reverse-engineering private IPC or relying on brittle UI automation.

In addition to the controls already listed in this issue, it would be useful for the API to cover the broader unified ChatGPT/Codex desktop workflow, including:

  • subscribe to agent/thread status changes (working, completed, waiting for input/approval, error, etc.);
  • get/set reasoning effort for the active composer/thread when supported;
  • attach images/files to the current prompt;
  • create a new thread/task;
  • switch the active folder/workspace/project;
  • respond to structured agent questions / select one of the presented choices;
  • start and stop microphone recording / dictation;
  • submit a prompt or the current composer contents;
  • discover and switch the active thread/task.

The goal is not to expose Codex Micro-specific lighting or HID internals. The useful abstraction is a device-agnostic desktop control API with versioned capabilities/events that any local controller can consume: Stream Deck, QMK/VIA keyboards, Loupedeck, MIDI controllers, custom USB devices, accessibility tools, etc.

Ideally this would be local-only and permissioned, with capability discovery and a documented compatibility/versioning contract. Security-sensitive operations (especially approvals) should remain explicit and auditable rather than being implemented through simulated keypresses.

This would effectively make the hardware integration extensible instead of limiting first-class desktop control to Codex Micro / Creators Micro2.

Related but narrower: #36041 asks for a stable read-only Agent Key status/lighting API. This request is broader and focuses on general desktop control and interaction primitives.