Direct answer
Codex Receipts
Codex finishes a run and gives you a summary: what it changed, what it ran, what passed. The summary is written by Codex, about Codex, and checking it means trusting it. Codex receipts are the stricter object: a record of each executed step, filed when the step ran through Zambo, the verifiable work layer for AI, that a reviewer, a client, or a teammate can verify without trusting the summary. Anyone checks a receipt free at zambo.dev/verify, no signup. This page covers the honest starting point, the routing, proof of execution vs logs, and the without screenshots workflow that replaces terminal pictures with records.
Updated October 20, 2026.
The honest starting point: what a Codex run leaves behind
A Codex session leaves three things: the changed code, a diff you can review, and the agent narrative about everything else. The diff is real evidence for the code itself. The narrative covers the rest: the commands it says it ran, the tests it says passed, the checks it says it performed. For the narrative, your evidence is the session output on a machine the presenter controls. That is the same weakness as every agent transcript, and it matters most exactly when the stakes rise: a freelancer delivering a build, a developer handing work to a lead, a small business owner paying for a fix they cannot read.
Nobody is accusing the agent of anything. The problem is structural. Records that convince second parties have to be checkable by second parties, and a session summary is checkable only by re-running the work, which defeats the point of having an agent do it. Codex receipts fix the structure: route the steps that carry claims, the verifications, the audits, the live checks, through a layer that files a record at execution time, and the claims stop resting on the narrative.
How to route Codex work through Zambo
Where Codex accepts MCP servers or external tool calls, add the Zambo endpoint: https://zambo.dev/mcp, one URL and no key, carrying 153 tools in total with 35 on the default surface. During the run, the steps you want on record, a source check, a site audit, a data pull, a price lookup, a delivery packaging step, execute through Zambo, and each saved result is filed with its verifiable receipt the moment it returns. The code edits stay in the repo where they belong; the evidence about the run accumulates alongside them.
For API driven use, Codex proof of execution API means the same routing from your own harness: your runner calls the Zambo endpoint for the verifiable steps, receipts come back with the results, and your pipeline stores the packet next to the artifact it describes. The format underneath is AER-1, an open IETF Internet-Draft (draft-zambo-aer1-24), so the record is readable by the public verifier and by independent tooling, not locked inside one vendor dashboard.
At delivery, assemble the receipts into a handover: one link with the goal, the steps in order, the outputs, the open items, and a decision control at the end. A client or reviewer opens it with no account and checks the steps that matter. That link is the Codex work receipt in the form people actually use: not a single slip for a single call, but the whole job, checkable end to end.
What a Codex receipt proves, and what it does not
Check a receipt at zambo.dev/verify and the verifier recomputes the saved result against the record filed when the step ran. A match proves the result you are reading is the result that came back at that moment, unchanged since. That is a narrow claim and it is the right one: it converts the agent narrative from a story into a set of testable statements. The test step ran, on this input, and returned this. The audit ran, on this target, and found this. Each statement now stands or falls on a check anyone can run free.
What the receipt never proves is that the work was good. A passing check with a receipt is a passing check; whether it was the check that mattered is engineering judgment, and the receipt leaves that judgment exactly where it belongs, with the reviewer. This honesty is a feature when you are the one presenting the record: a proof that claims only what it can prove survives hostile reading, and client side reviewers do read hostile when money is attached.
Codex proof of execution vs logs
The vs logs question decides whether receipts are worth the routing, so compare them directly. Logs and session outputs are stored by the environment that did the work. They scroll, they rotate, they can be filtered before they are shared, and the reader cannot distinguish a complete log from a curated one. As debugging material they are essential. As evidence they ask for trust, and trust is the scarce resource in a delivery dispute.
Proof of execution is filed outside the session at the moment of the run, in an open format, and verified by recomputation at a public verifier the presenter does not control. Edit the saved result afterward and the check fails where everyone can see it. That asymmetry is the whole value: the person presenting the record cannot quietly improve it later. Codex proof of execution without screenshots and proof of execution vs logs are the same search wearing two coats, and both are answered by the routed record.
Codex receipts without screenshots
The screenshot workflow for agent runs is grim: capture the terminal, crop the terminal, send a stack of images, and ask the client to believe the green text. Codex receipts without screenshots retire the ritual. The handover link shows the actual outputs of the routed steps, in order, each with a receipt the client can verify in seconds. A non technical buyer can run the check. A technical reviewer can go deeper. Nobody has to squint at a picture of a terminal and decide whether it looks authentic.
The link also ages better than images. Six weeks later, in a dispute or a follow up engagement, the same link still opens, the same checks still pass, and the record shows the client acceptance from delivery day. Screenshots in a chat thread are archaeology. A filed record is a reference. Freelancers and small teams feel this difference on the second job, when the returning client already knows how delivery works and asks for the link by name.
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:
Codex receipts for developers: attach the packet to the pull request or the ticket. Reviewers verify the routed checks in seconds and review the diff with provenance settled.
Codex receipts for freelancers: send the handover with the invoice. The client checks the run, accepts on the record, and the acceptance receipt closes the loop if payment is ever disputed.
Codex receipts for small business: an owner paying for agent built software gets a record they can check without reading code: steps in order, results attached, free verification at a public page.
Codex proof of execution API: harnesses and runners file receipts programmatically through the same endpoint, so automated Codex pipelines accumulate the same checkable trail as interactive sessions.
Codex verifiable receipt: verifiable means a stranger can recompute it. Open zambo.dev/verify, run the check, watch it pass or fail. No account and no permission from the person who sent it.
Codex work receipt: the work receipt for a whole job is the handover: goal, steps, outputs, receipts, open items, and the client decision, in one link that stays checkable.
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 change was the right change and the tests were the right tests. Second, the record only covers steps that ran through Zambo: work Codex 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 are Codex receipts?
Codex receipts are checkable records of the steps in a Codex run, filed when each step executed. Codex itself leaves a session summary, which is the agent own account of the run. Route the verifiable steps through Zambo at https://zambo.dev/mcp and Zambo executes those calls and files each saved result with a verifiable receipt. Anyone can check a receipt free at https://zambo.dev/verify/ with no signup, and the receipts for a whole job travel together in one handover link a client can accept or flag.
Does Codex itself issue Zambo receipts?
No. Codex does not issue Zambo receipts, and no honest page should say it does. Zambo records work that runs through the Zambo MCP endpoint: when a Codex session or a harness calls a Zambo tool, Zambo executes the call and files the result with a receipt. Code edits and local commands inside the session produce no Zambo record on their own. Route the steps that carry claims, the checks and verifications, and list anything unrouted as unchecked in the packet. The coverage is exactly the routed work.
What is the difference between Codex logs and proof of execution?
Codex session output and logs are kept by the environment that ran the work and presented by the person the record describes; they can be trimmed before sharing and a reader cannot tell. Proof of execution is filed outside the session at run time, in the open AER-1 format, and anyone can recompute it free at https://zambo.dev/verify/. Change a saved result after filing and the check fails openly. Logs help the operator debug. Receipts help a second party verify, which is what delivery, review, and payment disputes need.
How do I show Codex work without screenshots?
Route the load bearing steps through Zambo during the run, then send the handover link instead of terminal images. The link shows the goal, the steps in order, the actual outputs, and a receipt on each routed step. The client opens it with no account, checks any receipt free at https://zambo.dev/verify/, and accepts the job or flags a specific step. Nothing is cropped, nothing depends on a picture looking authentic, and the same link still verifies weeks later when a screenshot folder would be lost in a chat thread.
How much do Codex receipts 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.