Claude Code Adds Itself as Git Co-Author: What It Means and How to Disable It [2026]

If you have been using Claude Code to write code and committing the results, you may have noticed something in your git log: a trailer line reading Co-Authored-By: Claude Opus <[email protected]> appended to every commit the tool creates.

This is not a bug. It is a deliberate default behavior — and it sparked a debate on X that reached nearly 500,000 views in June 2026.

Constantine K, a software engineer, put the objection plainly:

"I strongly disagree with crediting Claude as a commit co-author. It is a tool I'm paying for, not a copyright holder, not an author. We don't credit Visual Studio."

The other side of the argument, from the replies:

"Not crediting Claude on your stuff when it's the one writing all the code is incredibly dishonest. You want to deceive people into thinking you're the one that wrote it?"

Both positions are coherent. The question underneath — who authored code that an AI wrote — is one the industry has not agreed on. But the practical question — how to control what Claude adds to your commits — has a clean, simple answer.

What Claude Code Adds, and Where

Claude Code appends attribution in two places by default:

1. Git commits — a Co-Authored-By: trailer line following the commit message body
2. Pull requests — a line at the bottom of the PR description crediting Claude Code

The specific format is:

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

The model name in the trailer reflects whichever Claude model version was active when the commit was made.

This trailer format is the same one GitHub uses for human co-authors on squash merges and collaborative commits — the same metadata that appears in git log --format=full and that GitHub renders as a contributor on the commit view.

The Attribution Settings in Claude Code

Claude Code exposes direct control over this behavior via settings.json. The relevant key is attribution:

{
  "attribution": {
    "commit": "Co-Authored-By: Claude Sonnet 4.6 <[email protected]>",
    "pr": "🤖 Generated with [Claude Code](https://claude.ai/claude-code)"
  }
}

This is the default. Both commit and pr are string fields — whatever string is set gets appended. Setting them to empty strings removes attribution entirely:

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

The setting lives in ~/.claude/settings.json for global effect, or .claude/settings.json inside a specific project for project-level override. Changes take effect immediately — no restart needed.

This was noted by multiple people in the original thread:

"Just turn it off dude. You can do it faster than writing a flame post on X."

"~/.claude/settings.json"

The docs page for attribution settings is at code.claude.com/docs/en/settings#attribution-settings.

How Cursor and Other AI Tools Handle This

Claude Code is not unique. AI attribution in commit metadata is a widespread pattern across AI coding tools.

Cursor adds similar attribution to commits it creates, typically in the commit message body or as a trailer. The exact format depends on version and configuration, but the default behavior is attribution-on.

GitHub Copilot does not automatically add co-author trailers to commits (since it operates at the suggestion layer rather than the commit layer), but its PR summaries and code review comments identify AI involvement.

Devin (the AI software engineer from Cognition) includes attribution in its PR descriptions and branch names, since it operates as an autonomous agent that creates entire PRs independently.

Aider (the open-source coding assistant) can be configured to sign commits with a custom author identity, and some users configure a dedicated "aider" git identity for this purpose.

The common thread: AI coding tools that create commits on your behalf face the same question Claude Code does, and most default to some form of attribution. The philosophy is transparency — commit history is a record, and if an AI agent is materially creating code, that should be visible in the record.

The Three Positions in the Debate

The X thread surfaces three distinct positions that are worth mapping cleanly:

Position 1: Claude is a tool, not an author

The "we don't credit Visual Studio" argument. Software tools that generate, transform, or suggest code are part of the development environment — not collaborators. Copyright law does not recognize AI as an author. Accountability for the code rests entirely with the human who committed it. Crediting the tool conflates authorship with tooling.

This position is strongest for legal and enterprise IP contexts. If you are working on code that will be submitted for a patent, licensed commercially, or reviewed for copyright ownership, mixing in AI "co-authorship" creates ambiguity that most legal teams prefer to avoid.

Position 2: If Claude wrote it, the commit should say so

The "honesty in the record" argument. If Claude wrote 80% of a commit, a git log that shows only a human author is misleading — to future maintainers, to auditors, to anyone trying to understand how the codebase was built. Attribution is not about legal authorship; it is about accurate provenance for the people who will maintain the code later.

This position is strongest for open-source projects and collaborative teams where commit history serves as institutional memory. Knowing that a specific component was AI-generated is relevant context for anyone modifying it later.

Position 3: Attribution should be configurable, not mandated

The pragmatic position — and the one Claude Code's design already adopts. The tool ships with attribution on, which surfaces AI involvement by default. The setting to disable it is one JSON line, which is less friction than a flame post. Whether to use it is a team decision, not a tool decision.

Most enterprise teams land here. The co-author line gets removed from the default configuration during team onboarding. Individual developers make their own call.

How to Disable It: Three Methods

Method 1: Global settings.json (Recommended)

Edit ~/.claude/settings.json:

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

This removes Claude attribution from all commits and PRs across all projects globally. It is the fastest and most complete fix.

If the file does not exist yet, create it:

mkdir -p ~/.claude
echo '{"attribution": {"commit": "", "pr": ""}}' > ~/.claude/settings.json

Method 2: Project-level settings.json

For a specific repo, add the same setting to .claude/settings.json in the project root:

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

This overrides the global setting for that repo only — useful if you want attribution in personal projects but not in a work codebase.

Method 3: CLAUDE.md rule

Add an explicit instruction to your project's CLAUDE.md file:

## Commit conventions

Never add "Co-Authored-By" lines to commits. Do not include Claude attribution 
in commit messages, PR descriptions, or any git metadata.

This is a second layer — Claude Code reads CLAUDE.md before creating commits. Combined with the settings.json change, it is belt-and-suspenders enforcement. Useful if you share a repo with other people who might not have the global settings configured.

The Skill and Memory Approach

If you use Claude Code across multiple machines or want to enforce the preference persistently without per-machine configuration, there are two additional paths:

Claude Code memory: Add the preference to Claude Code's memory system. In any Claude Code session, you can say "remember: never add co-author lines to commits" and Claude will save this to its persistent memory, applying it across future sessions.

Claude Code skill (SKILL.md): If your team uses a shared skills directory, create a skill file that includes the no-attribution instruction:

---
name: git-commit-conventions
description: Team git commit standards — apply when creating commits
---

When creating git commits:
- Never add Co-Authored-By or any AI attribution lines
- Never add Claude attribution to PR descriptions
- Commit message format: [type]: [description]

The skill approach makes the preference portable and team-wide without requiring every developer to edit their personal settings.json.

Why Anthropic Ships Attribution On by Default

The attribution behavior is not accidental or an oversight. Anthropic's documented rationale is transparency in the software development record.

The argument: as AI tools write an increasing share of production code, the distinction between "code a human wrote" and "code an AI generated that a human reviewed" becomes meaningful for maintenance, security review, and accountability. A commit history that accurately reflects AI involvement helps future maintainers calibrate how much the code was deliberately crafted versus generated and accepted.

The counterargument — and the one many developers act on — is that the tool-user boundary is clear enough without metadata. The engineer who reviewed the code, understood it, and committed it is accountable for it regardless of how it was produced. The same accountability applies whether you used Claude, Copilot, Stack Overflow, or a textbook.

Both positions have merit. Anthropic's design choice — on by default, trivially disablable — is a reasonable resolution: it surfaces AI involvement without making suppression difficult.

What This Means for Teams

If you are setting up Claude Code for a development team, the attribution setting is worth deciding explicitly during onboarding rather than leaving it to individual preference. Inconsistency — some developers with attribution on, some with it off — produces a git history that is neither consistently transparent nor consistently clean.

A few practical patterns:

For open-source maintainers: Many maintainers prefer attribution on. The commit history is public, AI involvement is relevant context for contributors, and the Co-Authored-By trailer is easily filterable in git log output.

For enterprise teams with IP concerns: Attribution off. Legal teams in most organizations prefer commit metadata that reflects human authorship for licensing and patent purposes.

For solo developers: Your call. If your commit history is primarily for your own reference, neither approach creates a practical problem.

For regulated industries (healthcare, finance, legal): Consult with your legal team before deciding. In some regulatory contexts, the provenance of code may be subject to audit requirements — and "how was this written" could be a relevant question regardless of what the commit says.

The Bigger Question It Points To

The commit co-author debate is a small surface area of a larger question the industry is working through: as AI writes more code, what changes about how we think about authorship, accountability, and code ownership?

The engineer who reviewed and shipped AI-generated code is accountable for it — that part is clear. Whether the commit history should reflect how the code was produced is a question about transparency and institutional record-keeping, not just attribution etiquette.

Claude Code's default — add the attribution, make it easy to remove — is a reasonable starting position while the industry figures out what norms actually serve developers and organizations best.

The one-liner to disable it is in your settings.json. Whether to use it is a decision worth making deliberately.

Attribution setting behavior described in this post is accurate as of Claude Code v2.1.x, June 2026. Check code.claude.com/docs/en/settings for the latest settings documentation.