Trust and cost
Before you give it a key
Who must be trusted, what the default reviewing agent can do, and where your code goes during a review.
Use Wachiman only where everyone who can push is trusted. GitHub runs the caller workflow from the
pull request’s own merge commit, so anyone who can push can edit the workflow that holds your key.
This is not a sandbox. For the default Claude Code workflow, the engine starts Claude Code with
--restricted, --strict-mcp-config and --tools Read,Glob,Grep: no shell, no MCP servers, the
reviewed branch’s own .claude/ settings ignored, and no GitHub token in the agent’s environment.
Those controls narrow what the branch can make the agent load or run. They hold only for the tested
Claude Code versions, managed Claude Code settings on the runner still apply, and none of this is
a guarantee against a malicious branch.
The diff and the files the agent reads go to your own model provider. The engine does not send them to infrastructure Wachiman operates.
The short version
Section titled “The short version”This summary describes the default Claude Code workflow. The Codex adapter is CLI-only, has no workflow integration yet, and runs under different controls described in its own reference page.
- Trust boundary
- Everyone who can push to the repository: a pull request can edit the workflow that holds the key. Automatic fork reviews are skipped. On-demand requests check the head repository and stop before reviewing a fork.
- The agent holds
- Read, Glob and Grep over the branch’s files, and calls to your model provider. No shell, no MCP servers, no GitHub token. This is limited to the tested Claude Code versions, and managed Claude Code settings on the runner still apply.
- The CLI holds
- The GitHub token. It posts the review as an ordinary comment, never an approval or a request for changes. It stops without posting if its credential check finds your API key, or text shaped like one, in the outgoing text; an encoded key can evade that check.
- Your code goes
- To your own model provider: the diff and the files the agent reads. The standard workflow sends nothing to a service run by this project. Your provider’s own terms apply to what it receives.
Some claims have not been tested, and the repository lists them as such. Read the list of unverified claims before relying on any of the above.
Other ways to install
Section titled “Other ways to install”Copying the engine files into your repository instead of calling the reusable workflow changes the trust picture: the copied engine then sits in the pull request’s own, editable repository. The reusable workflow is the preferred install. Read the security policy’s section on what is executed from the head before choosing.
In the repository
Section titled “In the repository”This page orients. The reference lives in the repository, versioned with the engine.