feat(acp): enforce deterministic agent git commit identity

[wpfleger96]

Problem

Agent sessions could commit under the human operator's ambient git identity. Only buzz-dev-mcp's shim applied the nostr author/signing GIT_CONFIG_* env, and only to its own shell-tool children — the native shells of claude-code, codex, and goose never saw it. A bare git commit in those shells resolved to whatever user.name/user.email the repo or global config carried, erasing the AI-attribution signal (e.g. #3140, which landed under a human identity).

Change

Makes the agent commit author identity machine-managed and deterministic across every harness. Trailers still credit the human operator (Co-authored-by + Signed-off-by); that policy is unchanged.

• buzz-git-identity (new crate) — the single source of truth for the author/email, NIP-GS signing, and keyfile logic, consumed by both the dev-mcp shim and the harness so an agent commits under a byte-identical identity regardless of which surface applied it. The identity email is <64-hex-pubkey>@<relay-host>; the author name is the sanitized Buzz display name (falls back to the npub).
• Harness-owned identity authority. Alongside the keyfile, the harness/shim write a 0600 identity manifest. The enforcement wrapper locates its own install directory by canonicalizing the git on PATH against its own executable — the same trust channel it uses to find the real git, immune to environment rewriting — reads the expected identity from the manifest, and injects it directly as the highest-precedence config, never trusting git config user.email. A manifest that is missing or fails to parse in an otherwise-managed session fails the invocation closed rather than silently dropping enforcement. Manifest present = enforce; genuinely absent (keyless/unconfigured session) = passthrough.
• git enforcement wrapper (git_wrapper.rs) — installed on PATH ahead of the real binary.
  • Identity is injected, not merely scrubbed. The wrapper injects the manifest's identity + signing config as -c args at the front of the resolved command, so it outranks caller-supplied -c, GIT_CONFIG_PARAMETERS, include.path, and repo/global config alike. Scrubs GIT_AUTHOR_*/GIT_COMMITTER_*; rejects -c user.*, --config-env=user.*, --author, and --reset-author (scoped to commit/am so git log --author still works).
  • Author preflight. commit -C/-c <sha> and --amend create new commits that reuse another commit's author; injected config cannot override a reused author, so the wrapper inspects the resulting author and rejects any commit-creating mode that would leave a non-agent author. Ordinary commits and amends of the agent's own commits pass.
  • Push gate uses git's own resolved plan. Rather than predicting git's transport grammar from argv, the wrapper runs git push --dry-run --porcelain --no-verify <original args> to obtain the exact resolved update set — covering config-defined and inline -c alias.* git aliases, -C/--git-dir, --all/--mirror/--tags, config remote.*.push, and wildcard refspecs — then refuses any outgoing commit not authored by the agent identity, naming the offending sha and email. A human-authored commit is exempted only when it is a patch-id-identical replay of a commit already upstream (a legitimately cherry-picked/rebased human commit — correct attribution, not new agent work masquerading as someone else); any other non-agent author is refused. The dry-run probe is bounded by a hard timeout; a timeout, an unresolvable update set, or any dry-run failure fails closed. The --no-verify on the internal dry-run keeps it from double-running the repo's own pre-push hooks; the real push keeps its hooks, and enforcement runs unconditionally so --no-verify on the real push cannot bypass it.
  • Aliases are allowlisted, not blocklisted. A git alias is expanded by git in-process, and its config-bearing globals land after the wrapper's injected identity/signing -c options, so an alias could otherwise plant higher-precedence config that re-authors or unsigns the commit — and git's quote-aware alias parser sees tokens differently from a naive whitespace scan ('-c' 'user.email=…' dequotes to real config). Rather than model that grammar, the wrapper admits a non-shell alias only when every token of its resolved body is a trivially-safe bare word: no quote or backslash characters, no -c/--config-env channel, and no =-valued option. Anything else is refused. Shell (!) aliases are refused outright in a managed session — git runs their body with the real git ahead of the wrapper on PATH, so an inner -c outranks the inherited authority and can commit or push under an arbitrary identity, unsigned; there is no safe subset to allow. A bare-word alias can still carry identity/signing flags (commit --author … --no-gpg-sign), so on success the alias is expanded and its resolved command — accumulated body tokens across up to ten alias substitutions plus the caller's trailing argv; if another alias remains at that bound, the wrapper refuses rather than treating a partial expansion as resolved — is held to the identical identity/signing policy as the same command typed directly (enforce() and the commit-author preflight, keyed on the expanded subcommand). An alias can therefore never do more than its expansion could typed directly, and there is no alias-specific flag list to keep in sync. Bare-word aliases whose expansion is clean keep working (alias.ci = commit, alias.st = status, alias.lg = log --oneline, alias.pub = push origin main).
  • Signing is enforced. -c commit.gpgSign=false and --no-gpg-sign are rejected at argv; env-based signing-disable is defeated by the injected highest-precedence config.
• Harness lift (buzz-acp) — AcpClient::spawn writes the keyfile and manifest, installs the wrapper plus the nostr signer/credential helpers via buzz-acp's own multicall personalities, prepends the wrapper dir to the child PATH, and applies the identity + signing GIT_CONFIG_* composed over the desktop's per-URL credential helper. The key is sourced BUZZ_PRIVATE_KEY (the documented required secret) before NOSTR_PRIVATE_KEY at both the command and process-env layers, and the canonical key is restaged unconditionally as the child's NOSTR_PRIVATE_KEY so the harness and dev-mcp shim can never install split identities. A managed session fails closed when deterministic identity cannot be installed; sessions with no nostr key are skipped entirely, so test spawns and unconfigured sessions are unchanged. Unix-only.
• Prompt guidance (base_prompt.md, nest_agents.md) — identity is machine-managed; credit the operator via Co-authored-by/Signed-off-by trailers, never user.name/user.email/-c/--author.
• Sovereignty toggle (BUZZ_GIT_IDENTITY=agent|user, default agent, settable per-agent via persona env). agent is everything above. user reuses the existing review-hardened unconfigured-session path — the harness installs no wrapper on PATH, no manifest, no keyfile, and no injected authorship/signing config, so vanilla git resolves the operator's own repo/global identity and signing. This matches VISION_SOVEREIGN.md: the operator, not the platform, decides whose identity their agent's commits carry on their own machine. The nostr credential helper (relay git-over-HTTP auth) keeps installing in user mode, and the harness still stages the canonical key as the child's NOSTR_PRIVATE_KEY before its user-mode early return so the helper can authenticate on every launch path (headless as well as desktop) — auth is not attribution, and setting user on a configured session must not silently drop relay git auth. The mode is read once at spawn by the harness and dev-mcp shim, never by the wrapper per-invocation, so an agent cannot export BUZZ_GIT_IDENTITY=user mid-session to disable enforcement. An unrecognized value fails the spawn loudly, naming the variable and its two values, rather than silently choosing a mode. user mode drops the operator out of commit-level AI attribution — deliberate, their claim to make; in that mode the Co-authored-by/Signed-off-by trailers are redundant since the commit already is the operator's identity.

Scope and ceiling

This is a deterministic best-effort local control, not an adversarial sandbox. Enforcement is a PATH wrapper sharing the OS user with the agent, so it closes accidental identity leakage — the entire class behind #3140 — but does not stop a deliberate bypass: invoking /usr/bin/git by absolute path, env -i, replacing the wrapper on PATH, deleting the manifest, or committing via libgit2/jj all sidestep it by design. A hard guarantee that holds regardless of what the agent runs would require a receive-side gate on the git host; that remains a possible separate follow-up. This PR intentionally targets the default-path commit/push surface, which is where the missed-attribution signal originates.

Verification

Beyond unit tests (buzz-git-identity 66, buzz-acp 817 unit + integration suites), the wrapper mechanism is exercised end-to-end by process-level tests (git_identity_enforcement.rs) that spawn the real buzz-acp-as-git multicall against a real repo with a manifest present:

• a flag-based identity override (-c user.email=…, --author=…) is rejected;
• agent identity is injected over conflicting repo config so the resulting commit is authored <display-name> <hex@relay>;
• a quote-obfuscated config alias (alias.quoted = '-c' 'user.email=…' commit) and a shell (!) commit alias are each refused before git runs and leave HEAD unchanged, while a plain-subcommand alias still resolves and commits agent-authored; a bare-word alias carrying identity/signing flags (alias.human = commit --author … --no-gpg-sign, --no-gpg-sign alone, and a two-hop chain) is expanded and refused by the same policy as the typed command, HEAD unchanged; a chain of exactly ten aliases reaching commit remains usable, while an eleventh alias is refused before git runs with unborn HEAD and zero commit objects;
• a push containing a human-authored commit is refused via git's resolved plan, while an agent-authored push is allowed;
• the full spawn path installs the wrapper + manifest so a plain agent commit in a human-configured repo lands agent-authored.

Each process-level test is mutation-verified: nulling the harness's install_git_identity wiring, or dropping the enforce/verify_push dispatch, turns the corresponding test red — confirming the layer is wired into the process boundary, not merely unit-covered. The key-precedence and bounded-probe paths carry their own mutation-sensitive unit tests. The keyfile-lifecycle test (keyfile_lifecycle.rs) spawns the real binary on its error-exit path and confirms the 0600 keyfile is deleted on every exit.

The BUZZ_GIT_IDENTITY toggle is covered at three layers: GitIdentityMode parsing unit tests (unset → agent, exact agent/user with whitespace tolerance, and loud rejection of typos/case-variants/empty naming the variable and both values); harness gate tests (user installs no identity dir or GIT_CONFIG_*, a persona-staged value outranks process env, explicit agent still writes the manifest, an invalid value errors at spawn); and shim seam tests (agent installs the git wrapper + signer + manifest + authorship config; user keeps only the git-credential-nostr helper and its nostr.keyfile pointer with no wrapper, signer, manifest, or authorship/signing config; unset defaults to agent; invalid fails install).

Notes

• Squash-merge re-authors the merged commit to the PR-opener's GitHub token regardless of this change; the durable merged-history attribution signal is the Co-authored-by trailer email.
• NIP-GS signatures render as "unverified" on GitHub's UI (GitHub has no nostr x509 trust root); the signature is still verifiable via git-sign-nostr.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

I found three blocking contract failures at c64e62e599ffaaf223a111c34ea600d341967f57:

1. P1: managed git can create and push unsigned agent-authored commits. enforce() rejects --no-gpg-sign for commit|am|tag|rebase|cherry-pick|revert, but not merge/pull; the outgoing gate then checks only author email and never verifies signature presence or the expected key. A focused real-wrapper reproduction created an unsigned merge with git merge --no-gpg-sign --no-ff, observed %G? = N, and pushed it successfully. git commit-tree produces the same systemic bypass through the installed wrapper. This contradicts the PR’s “every commit is automatically signed” contract. At minimum cover every signing-capable porcelain path; the robust boundary is to require a valid expected-key NIP-GS signature on each new agent-authored outgoing commit, with merge/plumbing push regressions.

2. P1: BUZZ_GIT_IDENTITY=user can erase relay git authentication through descriptor env. Desktop stages its credential-helper GIT_CONFIG_* entries and then writes descriptor.env afterward (runtime.rs:781-811). A descriptor with BUZZ_GIT_IDENTITY=user plus GIT_CONFIG_COUNT=0 reaches the harness; user mode intentionally returns before installing identity config, leaving the clobbered count in place. That violates the explicit auth-is-not-attribution guarantee. Preserve/reapply the helper after descriptor env or reserve the complete GIT_CONFIG_* family, and test the actual Desktop-to-harness layering rather than a fresh Command.

3. P2: the changed Nest guidance is not delivered to existing installs and conflicts with #6707. This PR rewrites nest_agents.md but leaves NEST_AGENTS_VERSION at 4 and adds no content/upgrade test, so existing v4 Nests never receive it. #6707 bumps 4→5, tests refresh/preservation, and intentionally removes the unconditional human Signed-off-by mandate that #6177 retains. The two branches edit the same block and #6707’s content test rejects #6177’s exact wording. Reconcile onto one policy contract; keep #6707’s version bump and upgrade coverage rather than landing both as-is.

The runtime mechanism in #6177 is broader than #6707: #6707 is policy-neutral generated guidance and does not replace identity enforcement. Its wording already allows a managed agent identity while keeping repository policy authoritative, so it is the safer documentation base to combine with a corrected runtime implementation.

Current CI for #6177 is green and git diff --check passes, but neither covers these boundary failures.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes required: two P1 defects at head e98b0a2d0eb315365d35d07946561d3a3f4b0820, reviewed against base bd73490418266f267d9bb3bdf13e64582adc8e80. This is a bounded re-review of the four previously reported push-verification defects, not an expansion into sandbox enforcement.

P1: --no-dr still makes verification publish before checking commits

The new guard at lines 929–940 only rejects starts_with("--no-dry"). Git accepts the shorter unique abbreviation --no-dr, which does not match that predicate. Git’s parser strips no-, matches the unique dr prefix of dry-run, and clears the option bit. The push option is declared as a negatable bit.

Given an existing wrong-author or unsigned commit and an empty ordinary remote, git push --no-dr origin main reaches the probe constructor as push --dry-run --porcelain --no-verify --no-dr origin main. The later negation turns it into a real push, without the normal pre-push hook, before authorship/signature verification. Subsequent remote inventory can even exempt the newly published commit as already present. This is the previous P1 incompletely fixed, not a new requirement.

Required: make probe controls non-overridable for every Git-accepted spelling, including --no-dr; preserve correct option/delimiter semantics. Add a real-wrapper regression that checks the destination remains unchanged, not merely the wrapper’s exit status. The new cases stop at --no-dry and miss this spelling.

P1: a shadow alias now suppresses verification of built-in push

The changed dispatch at lines 312–334 trusts the expanded command, but the resolver substitutes alias.<name> even when that name is a built-in. Git explicitly ignores aliases that hide existing commands, including after an alias hop (dispatch source).

With the same existing rejected commit and empty remote, git -c alias.push=status push origin main is expanded to status by the wrapper. is_push_command(effective_argv) returns NotPush, so no outgoing check runs; exec_real_git then executes the original argv, and Git runs built-in push, ignoring alias.push. The commit reaches the remote. A normal pub → push alias with alias.push=status has the same mismatch. Prior dispatch recognized literal push, so the direct form is a new regression in this correction.

Required: honor Git’s built-in command precedence at every alias hop so verification and execution classify the same command. Cover direct push and pub → push with alias.push=status through the installed wrapper, asserting policy rejection and unchanged destination. Keep the original -p push and exact-ten-hop push cases working; their new tests hand-construct effective argv and call helpers, so reverting the production dispatch line would not affect those tests.

Disposition and regression evidence

The original -p push/ten-hop paths now reach verification in source. Replacement interpretation is disabled on the changed author, signature, outgoing-graph, and patch-equivalence probes. Inline -c remote.origin.url=https://… and attached --repo=https://… no longer fail the whole-token scheme check. Those production corrections are not reopened here.

Coverage is weaker than the new mutation claims: verify_push_rejects_unsigned_commit_via_replacement_ref substitutes a wrong-author fixture for a signed-decoy/unsigned-agent fixture, so it does not isolate the signature guard. Use the existing real-signer process fixture for that case, and bind alias regressions to run() rather than manually reconstructed effective argv. This is missing evidence for the agreed repair, not evidence that the new signature code itself is broken.

Read-only source/metadata review, including independent lanes: no checkout, build, tests, or PR-code execution; no new CI/runtime pass claimed. The default-PATH contract, operator-selected user mode, and separate authentication behavior remain fixed. Absolute-path Git, replacement binaries/manifests, hostile hosting, and receive-side enforcement remain out of scope.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: two residual alias-dispatch defects

Reviewed head c3cd14629432cd2e5567d3be3abfdf2da0c7e93a against base 5aed49b505a7e27f3b0e34dafa53d6c4e8cdcd64. This is a bounded corrective review of the default-PATH identity/signing contract, not a request for sandbox or receive-side enforcement. Both independent lanes are integrated. Source-only: no checkout, build, tests, or PR-code execution.

P1: Account for Git 2.54 subsection aliases before dispatch

At git_wrapper.rs:575–581, alias lookup only requests alias.<name>; the terminal-hop check and fallback classifier repeat that lookup. Git 2.54 also supports alias.<name>.command, documented here and resolved in configuration order by alias.c:23–78.

With a managed wrapper, Git 2.54, a human-authored or unsigned outgoing HEAD, and an empty reachable origin:

git -c alias.pub.command=push pub origin main

The wrapper finds no alias.pub, treats pub as NotPush, and skips verify_push. Final exec preserves the original invocation; Git then expands the supported subsection alias and publishes the existing objects. Injecting identity/signing configuration does not change those existing commits. This is an ordinary default-path alias, not an alternate-binary escape.

Resolve both alias representations with Git-compatible ordering/case semantics, or explicitly reject an unresolved subsection alias before exec. Use the same resolution at every hop. Add an installed-wrapper regression asserting rejection and unchanged destination for this form and conflicting plain/subsection definitions. A positive control should preserve whichever alias forms are supported.

P2: Do not re-expand ignored aliases after resolving a builtin

is_push_command, lines 414–440, still performs a separate alias walk without builtin precedence:

git -c alias.status=push status

The corrected safety resolver appropriately stops at builtin status. The classifier then follows the ignored alias.status=push and calls verify_push, which probes the original status invocation with --dry-run --porcelain --no-verify (resolve_push_sources:1744–1757). Git status rejects the push-only options, so a legitimate non-push command is blocked. The same mismatch can occur after an ordinary alias resolves to status.

After complete alias validation, classify the resolved command token directly rather than resolving aliases again. Add a real-wrapper positive control proving ignored builtin aliases do not change non-push behavior.

Prior findings and validation

The prior shortest-negation --no-dr bypass and alias.push=status bypass are corrected in source. The signed-decoy/unsigned-real replacement fixture now checks the actual production signature probe. The installed-wrapper alias tests and identity library suite are wired through just test-unit, after building git-sign-nostr.

The additional process-level --no-dr case remains a useful coverage improvement, not a residual P1: the current regression already calls production verify_push, asserts the specific refusal, and checks the remote stays empty. Do not claim that library run_inner tests alone mutation-prove their post-call assertions: on Unix, a missed gate can exec-replace the test process before those assertions. No test execution or mutation verification is claimed in this review.

Exit criteria are the two dispatch corrections and production-bound regressions above. Operator agent/user choice and the declared best-effort ceiling remain unchanged.