ProofTrail matters to AI-agent builders for one practical reason:
it gives an agent stack a governed browser execution layer with retained evidence, guided recovery, and MCP, instead of only a one-shot browser bot.
This page is intentionally narrow. It does not claim that ProofTrail is a generic AI agent platform. It explains why an AI-agent team would still care about this repo.
It is also the right page when your team is evaluating ProofTrail as the browser-evidence layer behind Codex, Claude Code, OpenHands, OpenCode, OpenClaw, or another AI-agent shell.
You are trying to answer one of these questions:
This page is also the right landing page if your search sounded like:
browser automation for Codexbrowser automation for Claude Codebrowser automation for OpenHandsbrowser automation for OpenCodebrowser automation for OpenClawbrowser evidence layer for coding agentsMCP browser automation for AI agentsIf that is your exact search intent, continue with ProofTrail for Coding Agents and Agent Ecosystems after this page.
If you are still asking “can this repo produce one truthful baseline run at all?”, start with the canonical evaluation path first:
AI agents do not get a magic autonomy shell from ProofTrail.
They get four concrete things:
just runProofTrail does not claim a dedicated first-class Codex integration or a Claude-only runtime, and it does not claim first-party OpenHands, OpenCode, or OpenClaw adapters either.
The truthful fit is narrower and still useful:
That means the most honest search-intent mapping is:
| If you searched for… | The truthful fit here |
|---|---|
| browser automation for Codex | ProofTrail can be the browser-evidence layer behind a Codex-style agent loop |
| browser automation for Claude Code | ProofTrail can be the browser execution and evidence layer behind Claude Code style workflows |
| browser automation for OpenHands | ProofTrail can sit behind an OpenHands-style runtime as the browser-evidence and recovery subsystem |
| browser automation for OpenCode | ProofTrail can provide a governed browser tool layer beneath an OpenCode-style shell |
| browser automation for OpenClaw | ProofTrail can act as the browser workflow backend behind an OpenClaw-style gateway or tool router |
| MCP server for coding agents | ProofTrail exposes a governed MCP surface on top of the same backend and artifacts |
| browser automation API for AI agents | ProofTrail exposes a contract-first API for direct integration |
This is a strong fit for Codex-, Claude Code-, OpenHands-, OpenCode-, and OpenClaw-style agent stacks without pretending that ProofTrail is the whole coding agent.
That combination matters because most agent systems eventually hit the same moment:
the run already happened, and now you need to inspect it, compare it, recover it, or hand it to a human without losing trust.
If your team is searching for this category, the truthful intent usually looks more like:
This repo is trying to win those searches honestly by being strong at browser evidence, recovery, API, and MCP, not by pretending to be a generic autonomy product.
Many builders land here with a very direct search intent:
The truthful answer is:
That means the practical fit is:
If you need a vendor-specific plugin or a generic AI copilot shell, this repo is not pretending to be that.
ProofTrail is not trying to beat generic browser agents at open-ended roaming.
It is trying to win on:
If your need is “let the browser improvise freely,” this repo is not pretending to be that.
If your need is “let the agent use browser automation without losing the evidence and recovery story,” this repo is highly relevant.
Use this road when the AI system still needs one truthful baseline.
The rule is simple:
Start here:
Use this road when an external AI client should consume tools instead of raw REST calls.
The role split stays clean:
Continue here:
Use this road when artifacts already exist and an agent or operator needs help rebuilding or refining a flow.
The important boundary is unchanged:
Continue here:
ProofTrail fits best as the browser execution and evidence layer inside a larger system.
Think of the stack like this:
| Layer | What stays outside ProofTrail | What ProofTrail contributes |
|---|---|---|
| Agent shell | planning, tool choice, multi-step reasoning | governed browser-facing capability |
| Browser execution | raw browser scripts or helper-only replay | canonical run lane and retained evidence |
| Recovery and judgment | ad-hoc human debugging | explain, share, compare, and review packet surfaces |
| Integration | direct tool consumption by external AI clients | MCP surface over the same trusted backend and evidence model |
This is why ProofTrail can matter to AI agents without claiming to be the whole agent platform.
Once the category fit makes sense, move from positioning to contract:
node --import tsx contracts/scripts/generate-client.ts --verifyThat path keeps the story honest:
Use this order if you want the shortest truthful route from category fit to repo reality:
This page does not claim:
It only claims what the repo already supports: