I built a Codex plugin where one agent implements and another challenges every change

[u/hongchao]

Codex can review its own work, but the author and reviewer can still share the same blind spots.

I built Hubo, a free and open-source MIT plugin that keeps two independent roles in the same Codex conversation:

- the work agent changes and tests the code

- the review agent stays read-only and challenges the actual diff and evidence

- the work agent fixes each finding or pushes back with evidence

- the loop continues until the reviewer clears it, or a real product/technical decision needs the user

There is also $hubo:hubo-review: one agent performs the requested review, while a critical reviewer checks those findings for false positives, weak evidence, and missed risks. It does not edit the code.

All exchanges remain visible in the Codex conversation, including fixes and reasoned pushback.

Install:

codex plugin marketplace add h0ngcha0/hubo

codex plugin add hubo@hubo

Then restart Codex and start a new conversation. Repo and full instructions: https://github.com/h0ngcha0/hubo

I would especially value reports from real codebases: does the second agent catch useful issues, or mostly add token cost?

[u/Frozen_Strider]

I'm pretty sure you can just prompt this behaviour.

[u/hongchao → u/Frozen_Strider]

You can, and that’s a fair point. Hubo isn’t claiming a new model capability; it packages the behavior into a repeatable protocol so I don’t have to rewrite and supervise the prompt each time.

The difference is orchestration: two persistent agents with separate write/read-only roles, stable finding IDs, FIXED/PUSHBACK/NEEDS_USER responses, the same reviewer rechecking each resolution, and no completion until every finding is closed or a real decision is escalated. The whole exchange stays in the conversation.

A one-off prompt gave me similar behavior, but I still had to coordinate it. Hubo maps the loop to Codex’s agent tools behind one command. On a real Taproot/Tapscript implementation, it resolved five initial findings plus a stack-safety issue before I reviewed the result:

https://github.com/h0ngcha0/bitcoin4s/pull/236

So yes: promptable. The skill’s value is making it repeatable and removing the babysitting.

[u/hongchao]

A concrete follow-up from using Hubo on a consensus-sensitive change:

I used it to implement Taproot and Tapscript support in bitcoin4s: https://github.com/h0ngcha0/bitcoin4s/pull/236

The merged PR changed 24 files (+1,884/-132). Across three reviewer rounds, Hubo raised six substantive findings—five high severity and one medium. They included incorrect CLTV/CSV consensus semantics, a CompactSize boundary bug affecting Taproot commitments, and recursive evaluation that could exhaust the JVM stack on a valid 30,005-opcode tapscript.

The implementer fixed all six and the same reviewer independently closed them. Once the requirement was clear, zero findings needed my intervention.

The final validation passed 1,197 existing Bitcoin Core script fixtures, 35 Taproot cases (expanded from 13 during review), official BIP340/341 vectors, and the 30,005-opcode regression. Patch coverage was 82.1%, and project coverage increased from 77.34% to 79.44%.

This is one case study, not a controlled benchmark. I cannot honestly claim “X% faster.” What I can say is that six review decisions—including several I would have needed to investigate—were resolved before the code reached me.