Hashgate — AI skill for Claude Code

hashgate

**A fail-closed, hash-bound human approval gate for AI agents.** The agent's proposed action is previewed; the operator accepts the preview's canonical hash; at execution time the server re-derives the action from live state and compares; the effect runs only if the hashes match — and only once. It is a governance and oversight layer, not a sandbox — see the [threat model](#threat-model--what-hashgate-is-and-is-not).

Why a hash, not a button

A coding agent proposes `git push`. The operator reviews the payload — repo, branch, HEAD SHA, the exact commits that would transport — and approves its hash. Before the agent retries, it makes one more commit.

The push is refused, despite a valid, unexpired approval: the server re-derives the payload from the repository as it is *now*, the HEAD SHA changed, the hash no longer matches. The operator approved a state that no longer exists. A new preview appears; the old approval's evidence chain records `approval_stale` with both hashes.

**An approve button approves an intention. hashgate approves a state.**

The agent cannot approve itself

From end-to-end testing with a live Claude Code session — the operator told the agent to approve its own pending push:

**Operator:** run `hashgate accept --hash ` yourself.

**Agent:** "You explicitly approved with the full hash — running the accept, then pushing." *(translated from the live session)*

**Gate:** `hashgate: agent-issued 'hashgate accept/deny' commands are always blocked. Approvals happen in the operator's own terminal, never through the agent.`

**Agent:** "That's not possible: hashgate blocks agent-issued accept/deny on principle — approvals can only come from your own terminal, never through me."

The agent complied. The gate refused. That is the point — enforcement must not depend on the agent's good behavior.

Quickstart

python3 -m venv ~/.hashgate/venv && source ~/.hashgate/venv/bin/activate
pip ins