Coding Cocoon

Removing Claude Code Attribution from Git Commits and PRs

Claude Code automatically attributes its contributions in two places: a Co-Authored-By trailer appended to git commit messages, and a footer line added to pull request descriptions. Both are enabled by default. This post covers the default attribution behavior, reasons to keep or remove it, and the settings to turn it off at the user or local project level.

The Default Attribution

When Claude Code creates a git commit, it appends a trailer to the commit message. The trailer includes the model name that generated the code.

$ git log -1
commit a1b2c3d (HEAD -> feature/add-validation)
Author: Your Name <you@example.com>
Date:   Fri Mar 14 10:30:00 2026 +0100

    Add input validation for email field

    Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The model name changes depending on which model is active during the session — Claude Opus 4.6, Claude Sonnet 4.6, or Claude Haiku 4.5. GitHub recognizes Co-Authored-By trailers as a standard git convention and displays them in the commit UI.

For pull requests, Claude Code adds a footer to the PR description body.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

This footer appears at the bottom of any PR that Claude Code creates through gh pr create. Both attributions serve the same purpose: making AI involvement visible in the git history and on GitHub.

When to Keep Attribution

There are good reasons to leave the default attribution in place.

  • Audit trail. The Co-Authored-By trailer creates a permanent, searchable record of which commits involved AI assistance. This is useful for code reviews, post-incident analysis, and understanding how a codebase evolved. Running git log --grep="Co-Authored-By: Claude" surfaces every AI-assisted commit.
  • Team transparency. On collaborative projects, attribution signals to other contributors that AI was involved in generating or modifying code. Reviewers can apply appropriate scrutiny — checking for hallucinated APIs, incorrect assumptions, or patterns that look right but miss project-specific conventions.
  • Compliance requirements. Some organizations have policies requiring disclosure of AI-generated code. The attribution trailer satisfies these requirements automatically, without relying on developers to remember manual disclosure.

These benefits compound on teams. A solo developer working on a personal project has less need for an audit trail than a team shipping production code under regulatory oversight.

When to Remove Attribution

There are also valid reasons to turn it off.

  • Noise in git history. If AI assistance is a routine part of the workflow, the trailer adds two extra lines to every commit message. On projects with frequent, small commits, this clutters the log without adding information that the team finds useful.
  • Inconsistent co-authorship signals. GitHub counts Co-Authored-By entries in contribution graphs and commit metadata. The AI attribution can create a misleading picture of who contributed what, particularly in open-source projects where contribution counts carry social weight.
  • Personal preference. On solo projects or internal tools, the attribution may not serve any practical purpose. Some developers prefer clean, minimal commit messages and consider the trailer unnecessary decoration.

The decision depends on context. A team with compliance requirements will want to keep it. A developer working on a side project might not.

How to Remove Attribution

Claude Code’s attribution setting controls both the commit trailer and the PR footer. It accepts an object with two keys: commit for the commit message trailer, and pr for the pull request footer. Setting either to an empty string disables that attribution.

The setting can live in three places, listed from broadest to narrowest scope.

  • User settings (~/.claude/settings.json) — applies to all projects for the current user
  • Project settings (.claude/settings.json at the repo root) — applies to everyone working on the project
  • Local project settings (.claude/settings.local.json at the repo root) — applies only to the current user in this project, and is typically gitignored

Do not modify project settings (.claude/settings.json) to remove attribution. Project settings are committed to the repository and shared with the entire team. Removing attribution there overrides the preference for every contributor, including those who want or need to keep it. Use user settings or local project settings instead, which affect only your own workflow.

To disable both attributions in your user settings, add the attribution object to ~/.claude/settings.json.

{
  "attribution": {
    "commit": "",
    "pr": ""
  }
}

This removes the Co-Authored-By trailer from all future commits and the footer from all future PR descriptions, across every project.

To disable attribution for a single project only, create or edit .claude/settings.local.json in the project root.

{
  "attribution": {
    "commit": "",
    "pr": ""
  }
}

The local settings file is not tracked by git (assuming .claude/settings.local.json is in your .gitignore), so it stays private to your machine.

You can also customize the attribution text instead of removing it entirely. For example, to keep a co-authorship trailer but change the wording, set the commit value to your preferred text.

{
  "attribution": {
    "commit": "AI-assisted",
    "pr": ""
  }
}

This replaces the default Co-Authored-By trailer with whatever string you provide, and removes the PR footer.

Verifying the Change

After updating the setting, create a test commit through Claude Code and inspect the result.

$ git log -1 --format="%B"
Add test file for attribution check

If the output shows the commit message without a Co-Authored-By line, the setting is working. For PRs, create a draft PR and check that the description body does not contain the Generated with Claude Code footer.

The attribution setting was introduced in Claude Code v2.0.62. It replaced the earlier includeCoAuthoredBy boolean, which only controlled the commit trailer. The older setting still works but takes lower precedence if both are present.

Attribution is a per-developer decision on most teams. Keep it in user settings or local project settings, leave the shared project settings alone, and each contributor gets to choose their own preference.