Feature recommendation: harness-enforced adversarial commit review - a layered design beyond pre-commit hooks (working reference implementation + measured data)
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 22
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Summary
Recommendation: ship harness-enforced adversarial commit review as a first-class ZCode feature — an independent fresh-context reviewer must pass the exact staged diff before any agent commit, wrapped in a layered enforcement stack that goes well beyond a pre-commit hook. This is not a theoretical design: we run the full stack in production across our repos. Working reference implementation and measured data are available on request.
The problem
- Agents inject defects even into remediation commits written to fix a defect just found, and voluntary/self-requested review gets skipped under deadline pressure.
- Every client-side gate is advisory to the agent that holds the shell. The bypass classes are documented publicly: anthropics/claude-code#40117 (agents running
git commit --no-verify, stash, and quiet flags despite instructions), plus community mitigations for exactly that one flag (claude-cookbooks#346, claude-agent-sdk-python#703, Superset discussion). - The bypasses go far beyond a flag: git plumbing (
commit-tree+update-ref) never runs commit hooks;core.hooksPathcan be re-pointed; hook files in.git/hooksare untracked and deletable; a fresh clone is unarmed. - And the trivial bypass is not a flag at all: an agent can compute the staged sha256s and write the gate's own clearance/state file directly, forging the record the hook checks.
The community's block-no-verify guards are regex over one command form. The rest of the attack surface is untouched, and none of it produces durable evidence that review happened.
The honest claim (design principle)
No client-side scheme can prevent; it can only raise the cost and make bypass detectable. The layers need to be airtight against agents operating through the harness, and detect everything else after the fact. A human at their own shell is the owner — they get an audited one-shot OVERRIDE, not a wall.
The layered design (running in production)
| Layer | Where | Mechanism | Stops |
|---|---|---|---|
| 0 — the wall | pre-commit hook | independent model reviews the exact staged diff (bytes sha-pinned); findings block the commit | ordinary ungated commits |
| 1 | commit driver | runs check before commit, notarizes after | commits from disarmed clones through the driver |
| 2 | harness guard (tool-intercept) | denies bypass + forgery commands (--no-verify/-n, plumbing, hooksPath redirects, writes to the gate's state files) |
the agent-reachable workarounds |
| 3 — the tripwire (load-bearing) | post-commit notarization + auditor | durable git notes on refs/notes/adversary recording sha256 of every changed code blob + the reviewer's verdict artifact, written iff every blob matches a fresh CLEAR; an auditor recomputes every post-baseline commit and demands a matching note |
everything, after the fact |
| 4 | CI + branch protection | self-contained vendored auditor in CI; required check on main |
bypass reaching the shared remote |
Layer 3 is the trust anchor: absence of a note is the violation signal, so notarization is fail-closed — on any mismatch it writes nothing. It reads immutable OUTPUT (committed blobs), not process behavior, so no local trick escapes it.
The details that make it work
- Severity threshold: correctness/security/data-loss findings block; style never does.
- Baseline recorded at arming time — history before notarization isn't false-alarmed.
notes.rewriteRefconfigured so amend/rebase carries notes to rewritten commits: unchanged blobs keep valid clearance, conflict-resolved blobs correctly flag.- One-shot OVERRIDE with provenance: consuming it snapshots the staged shas; it can only bless the commit carrying those exact blobs — a lingering override file blesses nothing.
- Enforcement config itself is gated:
.githooks/and.github/workflows/paths require their own independent CLEAR to change (an edit to the gate is the highest-value attack). - A parity selftest asserts the vendored auditor's duplicated path rules can never drift from the gate's.
- Residual risks documented, not hidden: a determined fraudster can forge a note with correct shas and fabricated verdict text — but the embedded artifact makes fraud checkable (re-run a review against the same bytes). Detection, not prevention, by design.
Measured results (production)
- ~$0.006–$0.012 per review with current mid-tier models; seconds of latency; the author addresses findings and commits — normal workflow friction, dramatically fewer shipped defects.
- It blocks real bugs, not noise — most recent live example: it BLOCKED a commit whose diff could not prove a cross-file invariant (path-rule parity between gate and auditor) — a genuine drift defect class — then cleared it after verifying the author's factual rebuttal against on-disk facts.
- The reviewer runs with a rebuttal channel (
--context): findings are addressable with evidence, not vetoes.
The ask
Z.ai owns the harness — the one place enforcement can be first-class instead of bolted on. Ship "arm the commit gate" as a product feature: harness-level interception at the tool layer (beyond what any git hook or plugin regex can do), an independent reviewer verdict on the exact staged bytes, notarization into the repo as durable evidence, and a CI audit check for teams. For teams buying agentic coding, an enforced independent review gate is trust infrastructure — no competing agent ships it.
Working reference implementation (gate, harness guard, auditor, installer, selftests — the complete four-layer stack) and measured data available on request.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the proposed pre-commit hook, commit driver, harness guard, post-commit auditor, and CI check, then inspect the named .githooks/, .github/workflows/, and refs/notes/adversary paths. Request the working reference implementation and measured data mentioned in the issue. Done means the product has an agreed, independently reviewed design covering exact staged bytes, durable notarization, bypass detection, and CI enforcement.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git
- Domain
- ci-cd, devtools, security, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100