How to use Codex to build a USB bootstrap bridge
Codex built a phone-to-USB bootstrap bridge with independently observed terminal output. Review fixed queue ownership; remote-control claims remained limited.
devpost.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Implement a bounded phone-to-ESP32 BLE-to-USB-HID input path and a separate Go PTY return path. Use owned fixed-size queue frames with overflow handling. Verify actual target output rather than bridge acknowledgement, document observed evidence and leave Unicode, mouse control and production repeatability unclaimed until tested.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- daigo shirahama
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- A bounded ASCII input path and returned Codex marker were physically observed. Queue and transcript bugs were repaired; production repeatability and several advanced controls remained unproven.
- Human involvement
- Shirahama defined a bounded end condition, operated the physical input path and retained authority over hardware acceptance and final capability claims.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Shirahama defined a bounded hardware-input and independently observed terminal-output contract.
- Codex implemented the phone, firmware and companion layers, then repaired review-identified queue and path problems.
- The builder operated the physical path and checked the returned Codex marker in the declared environment.
daigo shirahama used Codex to build BOOTMUX, a bridge for reaching a computer before ordinary remote development was configured. An iPhone sent text over Bluetooth to an ESP32-S3, which presented it to the target as USB keyboard input.
The return path was deliberately separate. A Go companion owned the target terminal and sent actual PTY output back to the phone over a local WebSocket. A successful Bluetooth acknowledgement was not treated as evidence that the computer had executed the input. The demonstration observed bounded ASCII crossing the hardware and a real Codex result returning to the phone.
Independent GPT-5.6 review exposed a firmware ownership problem: non-trivial string objects were being copied through a FreeRTOS queue. Codex replaced them with bounded frames and explicit overflow handling. It also corrected transcript-path and open-writer behavior that could make separate processes silently disagree.
The builder checked the physical path and verified the runtime in a clean ARM64 VM. The submission clearly limits its result: production repeatability, Unicode, mouse input and some copy and mirror acceptance steps were unfinished. BOOTMUX therefore demonstrates a narrow end-to-end transport with observed output, rather than promising a complete remote-control appliance.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Devpost · daigo shirahama
Frequently asked questions
Why separate input and output paths?
Accepted keyboard input does not prove the target processed it; PTY output supplies a separate observation.
What caused firmware instability?
Raw-copy queue handling of non-trivial string objects created an ownership hazard.
Is all remote control finished?
No. Unicode, mouse support and production repeatability are outside the demonstrated slice.
More details
About this account
Shirahama defined a bounded hardware-input and independently observed terminal-output contract. Codex implemented the phone, firmware and companion layers, then repaired review-identified queue and path problems.
Original detailed submission opened. Bounded ASCII transport and a returned Codex marker were observed; repeatable production operation, Unicode, mouse support and several physical acceptance steps remain unproven. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: daigo shirahama — Devpost
Source published
Added to Agents In Use
Source checked
Tools and topics
Codex · ESP32-S3 · SwiftUI · Go · Lima
USB HID · Observed output
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.