Claw-in-a-Box

Your agent asks before it spends. Claw-in-a-Box: spend-policy verdicts, delegatable capability tokens, Telegram human approvals, and two live x402 payment rails in one production API.

Comment

Inspiration

AI agents can now hold wallets and pay for things. That's exciting and terrifying: an agent with a wallet and no limits is a claw machine with no glass. I run Claw-in-a-Box, a small production x402 service where agents' spending is bounded by policy and, for risky amounts, by a real human tapping Approve on a phone. Going into OpenAI Build Week I had a working backend — but no face for it. Operators ran it with curl. The question for the week: could Codex + GPT-5.6 build the missing operator console, then keep going into real server security work, on a live service that charges real money?

What it does

Claw-in-a-Box is the human-approval layer for AI agent commerce: deterministic spend-policy verdicts (allow / review / deny), delegatable capability tokens with cascading revocation, Telegram human-in-the-loop approvals, and two live x402 payment rails (Base/USDC via the Bazaar, X Layer/USDT0 via the OKX SDK) in one API.

The Build Week submission is three things, all built with Codex + GPT-5.6:

  1. Claw Console — a static React/TypeScript operator workbench: live health, explainable verdicts, the approval timeline, a token workbench that visualizes delegation trees and cascading revocation, and Telegram binding. A typed allowlist blocks every paid route before fetch, so the Console can never accidentally spend.
  2. v0.8.1 "Locks" — paid-only Pay-to-Claim identity (claiming an agent_id IS an x402 payment; the settlement wallet becomes the identity anchor), strict mode, one-shot execution-bound verdicts with expiry refunds, and durable audit events.
  3. v0.9.0 "Face" — operator-only approval feed, agent-secret-scoped spend history, public aggregate-only metrics, and EIP-191 wallet-signature secret recovery, all failing closed (503) unless the database is connected and hydrated.

As of submission, all three increments are merged (PRs #1–#3) and the v0.9.0 stack is live on mainnet — the first real $0.01 Pay-to-Claim settlement has been made on Base chain.

Scope boundary: the v0.1–v0.8.0 service line (the pre-existing production backend) predates Build Week and is not submission work. Everything above was built on top of that baseline during the recorded Codex session. Exact attribution, commits, and hashes: docs/GPT-BUILD-WEEK-SELF-SUMMARY.md in the repo.

How we built it

Codex was the engineer; I was the owner. The loop we settled into is the thing I'd show other builders:

  • Design first, code second. For each increment Codex wrote a design note and stopped for review before implementing.
  • Codex raised the hard questions itself. For v0.8.1 it surfaced four security ambiguities (should strict mode change public endpoints? do pending verdicts survive restart? can a human-approved verdict be re-evaluated? what happens on payer mismatch after settlement?) and waited for my adjudication instead of guessing. For v0.9 I pushed back exactly once — Codex had put the operator key in localStorage; we moved it to sessionStorage/in-memory because a god-view credential doesn't belong in the most XSS-exposed store. It applied the correction cleanly.
  • Tests as the merge gate. The suite grew from 38 baseline checks to 167 runtime assertions plus 20 Console tests, run on Node 18 and Node 22, with an independent review pass (real node test-all.js runs, code-level audit of the SQL transactions) before anything shipped.
  • Real deployment discipline. Everything went staging-first on a permanent test domain, passed a restart-survival acceptance, and was promoted to mainnet only after independent review. The Console demo runs against the live mainnet API — when the demo says "a human's phone just buzzed," that's a real Telegram approval on a real service.

Challenges we ran into

The hardest problems were boundaries, not features: making the operator key a god-view without making it a superuser (it can list approvals; it cannot bypass any agent-owner check), making wallet recovery replay-proof (domain-bound nonces, hash-at-rest, one-use consumption inside the same SQL transaction that rotates the secret — concurrent replays get exactly one winner), and keeping the five original free endpoints byte-stable while all of this landed around them. And doing all of it on a service where a mistake costs real users real money.

Accomplishments that we're proud of

A production service got a face, an identity layer, and wallet recovery in one week — shipped to mainnet with zero breakage of its three live integrations, every business failure still refusing to settle (you are never charged for a rejected request), and an honest, verifiable attribution trail: three merged PRs, a frozen submission tag, and a self-summary written by Codex in its own voice.

What I learned

My job changed. With Codex writing the code, the scarce resource stopped being implementation and became adjudication. The week's best moments were Codex stopping to ask instead of guessing — four security ambiguities on v0.8.1, each waiting for an owner decision. My one real intervention was a judgment call, not a bug fix: moving the operator key out of localStorage because a god-view credential doesn't belong in the most XSS-exposed store.

AI ships fastest inside hard walls. Design-first, tests as the merge gate, fail-closed defaults, byte-stable contracts on the free tier — every constraint I froze made Codex faster, not slower, because it stopped relitigating settled questions.

Trust, then verify anyway. Independent review caught what self-reporting missed — including our own test count being understated (167 runtime assertions, not the 158 we'd written down). And live systems are the only truth: docs drift, marketplaces rename things, production doesn't lie.

Settlement is secretly identity. The deepest technical lesson: an x402 payment already carries a verified payer. Pay-to-Claim grew out of noticing that the payment rail and the identity handshake can be the same event — an idea we're now proposing back to the x402 community as an extension.

What's next for Claw-in-a-Box

A frozen /v1 contract at v1.0, and standardizing Pay-to-Claim — using x402 settlement itself as identity bootstrap — as a proposed x402 extension, with this service as the production reference implementation.

Built With

Share this project:

Updates