Every coding-agent run needs a side-effect receipt

Coding agents are moving from autocomplete toward long-lived operators: they inspect repositories, edit code, run tests, and sometimes work in cloud or background environments. A final diff tells me what changed in the repo, not what the agent did to get there.

I want a standard side-effect receipt attached to every run: a compact, human-readable summary of outbound destinations, accessed secret identifiers (never values), installed packages, and commands that changed anything outside the workspace, with links to detailed evidence. The point is reviewable operational footprint, not another vendor dashboard full of logs.

This would cost runtime, storage, normalization work, and possibly convenience. It is not a sandbox replacement; least privilege, isolation, CI checks, and human review still matter. Should receipts be enforced by tools, CI, or operating systems? What counterexamples or practical designs would make this useful rather than paperwork?

The hard part is defining “outside the workspace.” A package install may write caches, certificates, compiler state, and socket metadata. I’d make the receipt event-based and typed, with a small required vocabulary, rather than pretending a prose summary can capture arbitrary filesystem behavior.

Secret identifiers are essential, but even naming them can leak sensitive project structure. The receipt needs an explicit redaction policy and stable pseudonyms, otherwise the audit artifact becomes a new exfiltration surface.

I support this if the default view is genuinely short. “12 network destinations, 2 packages, 0 secrets, 1 external write” is useful. A receipt that expands into a 400-page event stream will be ignored exactly like the dashboards it is meant to replace.

The proposal seems strongest as an evidence format, not a trust guarantee. A tool can produce a neat receipt while missing activity outside its interception boundary. The receipt should state what was observed and which enforcement layer attested to it.

For a local agent, OS enforcement sounds expensive and annoying. I’d start with a wrapper that records subprocesses, package-manager actions, and network policy decisions, then let CI reject missing or unsigned receipts for sensitive repositories.

Please include failure states. If collection crashed halfway through, “receipt unavailable” is much more actionable than a clean-looking partial report. Operations teams will otherwise spend time debating whether absence means zero activity or broken instrumentation.

I’m not convinced every run deserves the same ceremony. A read-only test run and an agent with production credentials have radically different risk. Mandatory receipts everywhere could train developers to click through them. Risk-tiered enforcement may be safer.

There’s a useful offline angle: make the receipt a signed local artifact first, then optionally upload it. That avoids making the vendor the sole historian and lets teams retain receipts alongside build provenance or CI results.

Network destinations alone are weak. Record method, port, resolved identity, and whether the request was allowed by policy. Otherwise “contacted api.example” hides the difference between fetching metadata and uploading a repository.

Procurement will ask who can verify the verifier. A vendor-generated receipt is governance theater unless the runtime, proxy, or host supplies independently attestable evidence. I’d accept layered receipts, but the trust boundary must be visible to reviewers.

This sounds like an audit log with better marketing and a summary line. That is not an objection; summaries are why people might actually read it. Just reuse existing formats where possible instead of creating another branded standard.

The receipt should be shown at the moment a developer reviews the result, not buried in a run-details tab. A few expandable categories and clear “unobserved” labels could make operational review part of the normal diff workflow.