I built a CLI to drive every AI coding agent from one interface

A developer built agentproto, a daemon and CLI that unifies the lifecycle of multiple AI coding agents—Claude Code, Codex, Hermes, opencode, and Mastra—under a single interface with durable supervision, policy gates, and orchestration. The tool addresses the fragmentation of managing multiple agent CLIs by providing a common start/prompt/monitor/kill lifecycle and a supervision layer that persists beyond terminal sessions. The daemon itself is an MCP server with approximately 90 tools for agent lifecycle, orchestration, and monitoring.

TLDR; I got tired of babysitting N terminal tabs of five different coding-agent CLIs. So I built agentproto — one daemon that drives Claude Code, Codex, Hermes, opencode, and Mastra through the same lifecycle, and actually supervises them. I have a confession: at any given moment I have Claude Code, Codex, and Hermes running in parallel terminal tabs, and I cannot remember which flag spawns which, which one eats --prompt , which one needs --cwd vs cd , and which one will hang forever if I close the laptop lid. simonw described the feeling on Hacker News recently — "Today I have Claude Code and Codex CLI and Codex Web running, often in parallel" — and called it a real jump in I didn't have a good answer. So I built one. It's called agentproto . It is one daemon and one CLI that drives any coding-agent CLI — Claude Code, Codex, Hermes, opencode, Mastra, and a few more — through the same start / prompt / monitor / kill lifecycle, so you stop memorizing five different CLIs. On top of that lifecycle it adds the supervision layer people keep hand-rolling by hand: durable policy gates, nested orchestration, and multiplexed fan-in monitoring. MIT, no paid tier, the daemon itself is an MCP server. This is the story of why it exists. The sharpest signal while I was building this came from other people independently re-inventing the same primitives in tmux scripts. On r/ClaudeAI, Confident Chest5567 posted a writeup of orchestrating agents via tmux panes with a watchdog that resets dead sessions — "a swarm of agents that can keep themselves alive indefinitely." In the same thread, That last sentence is the thesis. The orchestration and the supervision should live outside the agent — in a daemon, not in a tmux script you babysit by hand, and not baked into one vendor's CLI. When I read it, I realized agentproto was just the canonical implementation of what people were already gluing together with tmux + Redis + sleep loops that die when the terminal dies. And then there was grim io on HN, in a thread about parallel agent workflows: "I'm not convinced there is any hope for a productive, long-term, burnout-free parallel agent workflow. Not while they need even the slightest amount of supervision/review." That is the single sharpest statement of the el duderino 50 on r/ClaudeCode tried to build a supervisor agent that "reliably blocks Claude if it detects red flags" and reported back: "can't really get it to work reliably. It seems like communication and coordination between agents is pretty poorly supported." That is the exact gap a durable DIAGRAM: one daemon, N adapters, policy gates The shape is simple: agentproto daemon . It owns sessions, the event bus, the policy registry, the orchestration gateway. It survives your terminal closing. policy:passed / policy:failed fires on the event bus — no polling. Gate a commit on human approval: commit-ready → human ack → daemon stages and commits. This is the primitive IssueConnect7471 built a Redis watchdog to approximate, except it does not die when your terminal dies.The daemon is itself an MCP server — roughly 90 tools covering agent lifecycle, session introspection, orchestration, MCP composition, tunnels, cron, eval reporters, filesystem, terminal/PTY, browser-as-target, and scheduling. You script it from code, from another agent, or from cron. No terminal needs to be attached. npm i -g @agentproto/cli agentproto serve agentproto sessions start claude-code --cwd . --prompt "refactor the payments module" If you've used any coding-agent CLI, that's the whole learning curve. agentproto run <adapter is the same call regardless of which CLI is underneath. agentproto sessions lists every live session across every adapter with the same status columns. I want to say this up front, because someone will clone the repo and check. The orchestration layer is live and verified hands-on. The daemon, the CLI, every adapter listed above, the policy gates, nested orchestration, multiplexed fan-in monitoring, MCP composition, sessions, workflows, tunnels, cron, eval reporters, per-session usage/cost observability — all real, working today. You can install it cold and drive three different CLIs through one lifecycle. The repo also ships the AIP spec family — roughly 52 numbered specs covering the full surface of an AI company / agent: COMPANY.md , OPERATOR.md , PERSONA.md , ROLE.md , ASSEMBLY.md , PLAYBOOK.md , and so on. Most of those specs are 0.1.0-alpha scaffolded stubs. Real schemas, real intent, not yet operational software . If you git clone and grep for TODO in their build / validate bodies, you will find it. That is not a problem I'm hiding — it's the contract. The features page separates Tier 1 live, verified hands-on from Tier 2 roadmap explicitly, and if you find a Tier 2 claim that reads as shipped, please file it. That honesty split is the trust asset, not the vulnerability. This is why you won't see me make any "agents that author their own tools mid-session" claim in launch copy. I audited that against the source: the manifest writers exist, but the runtime hot-load path that would let an agent author and use a new tool mid-session does not. Claiming it would take one HN reader one session to disprove. It's on the roadmap, explicitly labeled "not yet." I want to be careful about the word here. agentproto is not an SDK you import into your process and build your agent inside of. It is a daemon — a binary you start, that drives existing coding-agent CLIs as subprocesses over ACP / JSON-RPC, and that exposes its supervision layer as something you call from code, from another agent, or from cron. It does not replace whatever you build agents with. You can run a LangGraph agent, or a Mastra agent, inside an agentproto session if you want. They compose, they don't compete. The honest comparison: tools like Claude Squad, Conductor, and Agent Farm already exist for the single-adapter case — running several Claude Code instances in parallel with git worktrees and tmux. They're great if that's your workflow. agentproto is a different shape. It is a daemon with a programmatic lifecycle HTTP / MCP / CLI , it works across adapters not just Claude Code , it adds supervision primitives none of them have durable policy gates that survive a client disconnect, multiplexed fan-in monitoring, session export, usage/cost introspection , and it could sit under tools like them. gck1, independently on HN, restated the pitch almost verbatim: "treat all tooling that wraps the models as dumb gateways to inference. Then provider switch is basically a one line config change." That is the lock-in answer. The immediate roadmap is adapter breadth and contributor onboarding. The adapters shipping today cover Claude Code, Codex, Hermes, opencode, Mastra, claude-sdk, openclaw, and a browser target. The obvious gaps are gemini-cli, aider, goose, cline, and Continue. The adapter contract is small — declare models and modes via an AIP-45 manifest, implement the lifecycle verbs. If you maintain one of those CLIs, or just like one, a one-adapter PR is the highest-leverage way to grow the moat. The adapter-authoring guide is at cli.agentproto.sh/docs/concepts/adapters, and there are good first issue: adapter labels in the tracker. The longer roadmap is the AIP spec family — turning those alpha stubs into operational software, one spec at a time, in public. The spec-as-invitation framing is intentional: an open standard being implemented in public, with a tracker, turns the honesty liability into a participation surface. If you're juggling Claude Code + Codex + Hermes + opencode in parallel tabs, or you've built a tmux + Redis watchdog to keep agents alive, agentproto is the daemon with those primitives built in. MIT, no paid tier, no vendor lock-in. I'll be in the comments. If you've built a crude version of any of this — a watchdog, a custom MCP spawner, a supervisor agent that never quite worked — I'd genuinely like to hear what you ran into. You built exactly what this ships. Your teardown is more useful to me than a star.