Direct answer

Claude Code Proof of Execution

Claude Code works in your terminal, and the terminal scrolls away. When a client or a lead asks whether the tests ran, whether the migration executed, whether the build passed, the evidence on hand is the session transcript: Claude Code reporting on Claude Code. Proof of execution replaces the report with a record. Run the load bearing steps through Zambo, the verifiable work layer for AI, connected to Claude Code as an MCP server, and each executed step files a verifiable receipt when it runs. Anyone can check it free at zambo.dev/verify. This page is the developer grade version of the receipt idea: what gets filed, what it proves, and where its limits sit.

See the check work before you trust the pitch: open the worked example handover at zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51, then check any receipt on it free at the public verifier. No signup, no account, nothing to install to check a record.

Updated October 20, 2026.

The honest starting point: a terminal transcript is not evidence

Claude Code sessions produce a lot of text and very little proof. The transcript shows commands as the agent narrated them, outputs as they streamed past, and a summary at the end written by the same agent that did the work. Scroll back and you can read it. Hand it to a client and they are reading a story told by the worker about the work. Terminal history has the same shape: it shows commands were typed into a shell on a machine the presenter controls, and it can be edited as easily as any text file.

The questions that actually start arguments are narrower than a transcript. Did the test suite run on the final code, or on the version from an hour earlier? Did the deploy step execute, or did the agent describe the deploy it intended? Did the data migration touch the production table? A transcript answers all of these with the agent word. A receipt answers the routed steps with a record filed at execution time, checkable by the person asking. For developers the distinction is familiar from CI: nobody accepts a screenshot of a green terminal as a build result when a CI record exists. This is the same instinct, applied to agent sessions.

How to route Claude Code work through Zambo

Claude Code takes MCP servers in its settings, so add Zambo the same way you add any server: point it at https://zambo.dev/mcp, one URL and no key. The endpoint carries 153 tools in total, 35 on the default surface, including the checks and lookups a coding session leans on: source and price checks, page and site audits, data extraction, and the handover tools that package a job. When Claude Code calls one of those tools during a session, Zambo executes the call and files the saved result with its receipt immediately.

The discipline is in choosing which steps to route. The edit itself is local work; the verifications around the edit are what a reviewer wants proven. Run the test pass, the audit, the live check, the extraction, and the delivery packaging through the connected tools, and say so in the session instructions: verify through the tools and keep the outputs. The resulting record covers the claims a reviewer actually tests: this check ran, on this input, and returned this result, at this time. Steps that stay local stay unrecorded, and the honest packet says so rather than implying blanket coverage.

Delivery is the handover: one link carrying the goal, the routed steps in order, their outputs and receipts, and the open items. A client, a lead, or a reviewer opens it with no account, checks the receipts that matter, and accepts or flags. For open source maintainers, the same link works in a pull request thread: the record of what the agent ran sits next to the diff, and any reviewer can check it without trusting the contributor machine.

What a receipt for a Claude Code step looks like

Each receipt names the tool, the input, the saved result, and the execution time. Check it at zambo.dev/verify and the verifier recomputes the saved result against the filed record: a match confirms the result was not altered after the run; a mismatch fails publicly. For a coding job, the chain reads like the session should have read all along: the repository state checked, the failing test reproduced through a tool, the fix verified, the audit run, the delivery packaged. Each link in that chain is independently checkable.

Notice what the receipt does not do: it does not grade the code. A receipt for a passing check proves the check ran and returned that result; whether the check was the right check is a review question, and it stays a review question. That separation is what makes the record credible to engineers. It claims exactly one thing, that this saved result is the result that came back when this step ran, and it lets anyone test that claim for free.

Claude Code proof of work vs logs

The vs logs comparison is where developers push hardest, so here it is without varnish. Shell history, session transcripts, and application logs are all kept by the environment that produced the work. They are indispensable for debugging and worthless as third party evidence, because the presenter controls the store. Anyone who has watched a log get truncated before an incident review knows the failure mode is not hypothetical.

A Zambo receipt is filed outside the session, at execution time, in the open AER-1 format (IETF Internet-Draft draft-zambo-aer1-24), and the verification is a recomputation a stranger runs at the public verifier. The session cannot reach back and tidy it. That is the entire argument for Claude Code proof of execution: not that agents lie, but that records meant to convince other people should not depend on the presenter honesty or the presenter machine. Keep your logs for debugging. File receipts for the steps someone else will judge.

Shipping the record with the work

The practical workflow ends in one of three places. For client work, the handover link goes in the delivery message and next to the invoice: here is the change, here is the record of the checks, accept or flag. For team work, the link goes in the pull request or the ticket, where reviewers already live, and the receipt checks replace the ritual of asking for terminal screenshots. For small business owners buying development help, the link is the first deliverable that lets a non technical buyer verify a technical claim without hiring a second developer to audit the first.

One habit makes all three work: file the record as you go, never reconstruct it afterward. Receipts exist because the steps ran through the endpoint during the session. A packet assembled from memory after the fact is just another transcript with better formatting. Route the checks live, let the record accumulate, and delivery becomes a link you already have.

Notes for your situation

The searches behind this page come in flavors. The record does not change; what changes is who checks it and why:

Claude Code proof of execution for developers: put the receipt check in review: the reviewer opens the handover, verifies the two or three load bearing steps, and spends review time on the diff instead of on provenance.

Claude Code proof of execution for freelancers: a solo developer delivering through an agent session sends the record with the build. The client acceptance on the handover closes the job in writing.

Claude Code proof of execution for small business: owners who cannot read code can still read a record: steps in plain order, results attached, checks that pass at a public verifier. It is the first technical evidence a non technical buyer can actually use.

Claude Code proof of execution open source: maintainers reviewing agent assisted contributions get the run record next to the patch. The format is an open draft with public test vectors, so the checking side is inspectable too.

Claude Code proof of work for agencies: agencies running agent assisted builds across clients send one packet per delivery: consistent shape, checkable steps, and a client only acceptance that ends the sign off chase.

Claude Code proof of work for clients: clients receive the goal, the steps, the outputs, and the receipts in one link, and flag the exact step they dispute instead of rejecting the whole delivery on a call.

Claude Code proof of work for teams: the record outlives the session and the sprint. Six weeks later, the question of what ran is answered by the packet, not by whoever remembers the terminal best.

What it costs

Public handovers are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. Frame it against the problem on this page: one payment turns a day of AI work from a claim into a record that anyone can check, which is the difference between arguing about a job and closing it.

Honest limits

Three edges, stated plainly. First, a verifiable receipt proves the saved result was not changed after the fact; it never proves the work was correct, well judged, or worth what you charged. The reviewer still judges whether the tests were the right tests and the code is any good. Second, the record only covers steps that ran through Zambo: work Claude Code did entirely on its own, outside the routed calls, has no receipt, and an honest packet lists that work as unchecked instead of pretending it is covered. Third, a receipt is a record, not a legal contract or a payment: pair it with your normal agreement and invoice, and let each document do its own job. AER-1, the receipt format underneath, is an IETF Internet-Draft (draft-zambo-aer1-24), not a finalized standard.

Frequently asked questions

What is Claude Code proof of execution?

Claude Code proof of execution is a record, filed when a step runs, that a reviewer can check without trusting the session transcript. Claude Code itself leaves a transcript, which is the agent account of its own work. Connect Claude Code to Zambo at https://zambo.dev/mcp as an MCP server, route the verification steps through its tools, and each executed step produces a verifiable receipt. Anyone can check a receipt free at https://zambo.dev/verify/, and the steps for a job travel together in one handover link.

Does Claude Code itself issue Zambo receipts?

No. Claude Code does not issue Zambo receipts. Zambo records the calls that run through the Zambo MCP endpoint: when Claude Code calls a connected Zambo tool, Zambo executes it and files the saved result with a receipt. Local edits, local shell commands, and anything else the session does outside the routed calls produce no Zambo record. Choose the steps a reviewer will care about, the checks, audits, and verifications, and route those. An honest packet lists unrouted work as unchecked.

How is this different from Claude Code logs or terminal history?

Terminal history and session transcripts are kept on the machine and in the account of the person presenting them, and they can be edited like any text. A Zambo receipt is filed outside the session at execution time, in the open AER-1 format, and verification is a recomputation anyone runs free at https://zambo.dev/verify/. Alter the saved result by one character and the check fails in public. Logs tell you what the session says happened. Receipts let a second party test what happened, which is what review and disputes actually need.

Can a client or maintainer check the record without an account?

Yes. That is the design. The handover link opens in a browser with no account and no signup, showing the goal, the steps, the outputs, and the receipt on each routed step. Checking a receipt at https://zambo.dev/verify/ is free and needs nothing installed. A client accepts the job or flags a named step from the same page, and only the client can do it: the creator of the handover is refused. A maintainer gets the same view in a pull request thread, with the same free checks.

How much does Claude Code proof of execution cost?

Checking any receipt is free at https://zambo.dev/verify/, and public handovers are free to send and free to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, which runs 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.

Related