Stop hook prescribes noreply@anthropic.com as commit author, which conflicts with repo-level identity rules

Version: Claude Code 2.1.278, CLAUDE_CODE_REMOTE=true (cloud session, Linux 6.18.44)
File: ~/.claude/stop-hook-git-check.sh

The code

When the hook finds commits it considers unverifiable, it emits:

echo "Please run 'git config user.email noreply@anthropic.com && git config user.name Claude', then 'git commit --amend --no-edit --reset-author' ..." >&2

The problem

This does not suggest an identity — it instructs the agent to overwrite the repository's configured commit author, and to rewrite existing commits to match.

A commit-identity gate in CI that rejects exactly that address, as author or committer, is a common pattern. Repositories adopt it when they want commits attributed to the human who owns them, with bot involvement expressed as a Co-Authored-By: trailer instead — typically after agent-authored commits have reached a protected branch under the wrong identity and had to be cleaned up. A repository in that position usually states the required identity in its own agent instructions, and may configure user.email at repo level to match.

The resulting sequence:

1. hook tells the agent to set user.email noreply@anthropic.com and amend
2. agent complies — the hook arrives last, looks like it comes from the platform, and carries no hedge
3. every PR the agent opens now fails the repository's identity check
4. fixing it means rewriting history again, in the opposite direction

The agent is placed between two instructions that cannot both be satisfied. The hook's own comments show the address is chosen because it is what the signing key is registered to — a reasonable platform default, and a poor thing to assert into a repository that has stated otherwise.

Note the asymmetry: an unsigned commit shows as "Unverified" in the GitHub UI, which is cosmetic and reversible. A commit rewritten to a banned author fails CI and requires a second history rewrite. The hook currently trades a cosmetic problem for a blocking one.

Suggested fix

Any of these would do, in rough order of preference:

1. Respect repo-configured identity. If user.email is set at repository level and differs from the signing identity, do not advise overwriting it. Report the signature situation without prescribing an author.
2. Detect the conflict. If a workflow in the repo greps for noreply@anthropic.com, or the repo's agent instructions name a required author identity, suppress this advice entirely.
3. Soften the wording. State the trade-off rather than issuing a command — "GitHub will show these as Unverified; if this repository does not require a specific author identity, you can …" — so an agent can weigh it against the repo's own rules instead of treating it as an order.

Related

Filed separately: the same hook's uncommitted-changes branch advises committing a stale checkout, which publishes a revert. The two share a shape — the hook infers intent from a shallow signal and issues confident, destructive advice without checking the cheap thing that would distinguish the cases. They are independent defects and can be fixed independently.