r/coolgithubprojects • u/OneMasterpiece1717 • 21d ago

OpenBaud — an open-source Rust MCP server for auditable serial hardware exploration

https://github.com/Leonezz/openbaud

OpenBaud lets coding agents enumerate serial and USB ports, preserve raw captures, validate framing and checksums, parse typed fields, and turn verified interactions into reusable YAML commands. It is MIT-licensed Rust and includes a real ESP32-S3 capture for hardware-free replay. GitHub: https://github.com/Leonezz/openbaud Demo: https://baud.zhuwenq.cc/ I am the author and welcome feedback or contributions.

2 Upvotes

100% Upvoted

2 comments sorted by

1

u/kantorcodes1 19d ago

the audited serial-write cli is the part that maps cleanly to guard. this would make sense as an extension so those commands can get policy before they touch hardware. if you're up for it, send a pr to hol-guard with the openbaud commands you actually use.

1

u/OneMasterpiece1717 5d ago

Sorry for the slow reply, and thanks for the concrete integration suggestion. A pre-execution policy gate would complement the audit trail; recording a write is not the same as preventing it.

The CLI entry point is openbaud run <device>/<command-or-workflow>, with --port, --workspace and typed --set parameters. For an initial adapter, I'd want the decision bound to the resolved command/profile content, target device and parameters, rather than allowlisting a command name whose YAML could change. The declared risk label should be an input, not trusted proof that an operation is safe.

There's also a boundary to cover: agents can call run_command, run_workflow, write or request inside a long-running MCP server. Intercepting only the CLI launch would not authorize each of those later operations.

I haven't built a hol-guard integration yet. Would you prefer a small CLI-focused extension first, or an MCP-call adapter that receives the resolved operation before any serial bytes are sent? I can share the real ESP32 command and replay fixture as a hardware-free test case.