The idea in one sentence
Add an optional coding-controller application profile to the OpenFlight ecosystem so a HOTAS, throttle, button box, or cockpit panel can control coding agents such as Codex, Claude Code, and future agent backends.
Think of it as a programmable coding macro pad and agent-status panel, using flight-sim hardware people may already own:
HOTAS / throttle / panel
-> OpenFlight normalizes the physical controls
-> a coding-controller profile maps them to safe agent actions
-> Codex, Claude Code, or another coding agent receives the request
-> agent state can later return to MFDs, LEDs, or panels
This issue is the plain-language proposal. The detailed engineering tracker is #309.
What would it do?
A first input-only profile could map controls like:
| Physical control |
Coding-agent action |
| Hat up/down |
Select previous/next action |
| Hat left/right |
Change action page |
| Thumb button |
Arm the selected action |
| Trigger |
Confirm the exact armed action |
| Cancel/pickle button |
Cancel or interrupt |
| Encoder |
Select workspace, agent session, or target |
| Mode switch |
Explicitly enter/leave coding-controller mode |
Example actions might include:
plan the next task
implement the selected work item
run tests or quality gates
review the current change
open the latest receipt/evidence
cancel or interrupt the running agent
The primary stick and throttle axes would remain unbound initially. The goal is not to “fly the model” continuously; it is to make common agent operations tactile, deliberate, and easy to monitor.
What is Runbook?
The first application integration is called Runbook.
Runbook is a local Rust control layer between physical control surfaces and coding tools. It owns the application semantics and safety rules:
- which workspace or agent session is selected;
- which action is highlighted or armed;
- exact arm/confirm/cancel behavior;
- prevention of stale or duplicate confirmation;
- truthful agent state;
- local pairing and authorization;
- adapters for Codex, Claude Code, and other backends.
OpenFlight would not learn Runbook commands or coding-agent semantics. It would expose a generic, application-neutral stream of normalized controls. A small external bridge/profile would translate those controls into Runbook actions.
Why OpenFlight is a good fit
OpenFlight already owns the difficult hardware-facing parts:
- device discovery and identity;
- report parsing;
- calibration and normalization;
- button, hat, encoder, and axis handling;
- real-time safety boundaries;
- profiles and device feedback infrastructure.
That makes a coding controller another application target, not another ad-hoc HID implementation.
The intended boundary is:
OpenFlight
owns hardware facts and normalized control events
Runbook / coding application
owns what those controls mean to a coding agent
Safety and activation
A HOTAS may also be used for flying, so coding controls must never remain globally active by accident.
The initial design requires an explicit Runbook/coding mode:
- a dedicated mode switch or profile activates the coding layer;
- inactive controls do nothing to Runbook;
- disconnect or reset deactivates the layer;
- the initial state of a held trigger never counts as a fresh press;
- confirmation applies only to the exact action the application last presented;
- cancel/interrupt remains available as a separate, deliberate control.
A future control-claiming/profile-overlay feature may prevent the same button from also reaching a simulator, but the first program is observe-only and input-only.
What the first demo should prove
1. Start OpenFlight with a simulated/replay HOTAS.
2. Activate the coding-controller profile.
3. Use a hat to select an action.
4. Arm it with a thumb button.
5. Confirm it with the trigger.
6. Runbook sends exactly one bounded action to a coding agent.
7. Reconnects, held buttons, and duplicate events do not repeat it.
The first proof can use replay fixtures and does not require a physical HOTAS.
Potential later feedback
After input is proven, OpenFlight could optionally project agent state to validated hardware outputs:
IDLE
RUNNING
WAITING FOR INPUT
WAITING FOR PERMISSION
COMPLETE
BLOCKED
UNKNOWN / STALE
Possible surfaces include MFD text, LEDs, RGB, and low-amplitude tactile cues. Those are separate hardware-validated lanes; no display or haptic support is implied by this proposal.
Initial scope
- buttons, hats/D-pads, and encoders;
- explicit coding-mode activation;
- input-only integration;
- generic non-real-time control stream;
- Runbook as the first consumer;
- Codex, Claude Code, and future coding backends behind Runbook adapters;
- replay and simulated proof before hardware claims.
Explicit non-goals
- putting Codex, Claude Code, or Runbook-specific commands in OpenFlight core;
- network or application work on the protected real-time path;
- approving unknown permissions, publishing, or deploying from a blind hardware button;
- controlling reasoning continuously with an analog throttle;
- MFD, LED, RGB, haptic, or FFB output in the first implementation;
- claiming broad HOTAS support from replay-only tests;
- replacing normal OpenFlight simulation profiles.
How this differs from a dedicated coding keyboard
A dedicated coding keyboard offers one polished hardware SKU. This proposal makes the same category of interaction available across existing HOTAS, throttles, panels, and button boxes, while preserving OpenFlight's device support and profile model.
The coding-agent integration remains replaceable: Codex, Claude Code, and other backends can share the same physical profile through Runbook rather than requiring a new hardware plugin for each agent.
Related trackers
Feedback requested
Useful feedback includes:
- which HOTAS controls are genuinely comfortable for coding workflows;
- which controls should remain simulator-only;
- what activation mechanism would prevent accidental dual use;
- which agent actions deserve physical controls;
- which status indicators would be most useful on MFDs or LEDs;
- whether the generic OpenFlight control stream is useful to applications beyond Runbook.
The idea in one sentence
Add an optional coding-controller application profile to the OpenFlight ecosystem so a HOTAS, throttle, button box, or cockpit panel can control coding agents such as Codex, Claude Code, and future agent backends.
Think of it as a programmable coding macro pad and agent-status panel, using flight-sim hardware people may already own:
This issue is the plain-language proposal. The detailed engineering tracker is #309.
What would it do?
A first input-only profile could map controls like:
Example actions might include:
The primary stick and throttle axes would remain unbound initially. The goal is not to “fly the model” continuously; it is to make common agent operations tactile, deliberate, and easy to monitor.
What is Runbook?
The first application integration is called Runbook.
Runbook is a local Rust control layer between physical control surfaces and coding tools. It owns the application semantics and safety rules:
OpenFlight would not learn Runbook commands or coding-agent semantics. It would expose a generic, application-neutral stream of normalized controls. A small external bridge/profile would translate those controls into Runbook actions.
Why OpenFlight is a good fit
OpenFlight already owns the difficult hardware-facing parts:
That makes a coding controller another application target, not another ad-hoc HID implementation.
The intended boundary is:
Safety and activation
A HOTAS may also be used for flying, so coding controls must never remain globally active by accident.
The initial design requires an explicit Runbook/coding mode:
A future control-claiming/profile-overlay feature may prevent the same button from also reaching a simulator, but the first program is observe-only and input-only.
What the first demo should prove
The first proof can use replay fixtures and does not require a physical HOTAS.
Potential later feedback
After input is proven, OpenFlight could optionally project agent state to validated hardware outputs:
Possible surfaces include MFD text, LEDs, RGB, and low-amplitude tactile cues. Those are separate hardware-validated lanes; no display or haptic support is implied by this proposal.
Initial scope
Explicit non-goals
How this differs from a dedicated coding keyboard
A dedicated coding keyboard offers one polished hardware SKU. This proposal makes the same category of interaction available across existing HOTAS, throttles, panels, and button boxes, while preserving OpenFlight's device support and profile model.
The coding-agent integration remains replaceable: Codex, Claude Code, and other backends can share the same physical profile through Runbook rather than requiring a new hardware plugin for each agent.
Related trackers
EffortlessMetrics/runbook-rs#32EffortlessMetrics/runbook-rs#40EffortlessMetrics/OpenRacing#672Feedback requested
Useful feedback includes: