Here’s a question that sounds trivial until you try to answer it at fleet scale: when an AI assistant helps write a commit, whose name goes on it?
The default answer, for a lot of teams, was decided for them. If you run Claude Code, it has — by default
— been appending Co-Authored-By: Claude <[email protected]> to your commits. Developers noticed, and they were not universally thrilled. One Ask HN thread
is a small monument to the irritation: “I don’t give VS Code credit or my keyboard and mouse.” Someone else went further and wrote a tool whose entire purpose
is to swap the Claude trailer out for random fictional characters. The Tell HN
version of the argument was blunter still: the trailer is effectively free advertising, riding into your git history on the back of your work.
This month, across the entire Forge fleet, we made a deliberate call on it. Here’s the honest write-up.
What we changed
Two things shipped together (Forge fleet, week of June 30 – July 2):
- We dropped
Co-Authored-By: Claude <[email protected]>everywhere. The workflow engine, the cloud-exec worker, and the Claude-via-Bash path all stopped emitting it. On the runtime side that meant settingincludeCoAuthoredBy: false— the same escape hatch the HN thread surfaced — so no Forge agent silently name-drops a model vendor into your history. - Where we do record AI assistance, we now use
Assisted-By:— notCo-Authored-By:. That’s not a cosmetic rename. It’s a claim about what actually happened.
Because those two words mean genuinely different things, and getting them right is the whole point.
Co-Authored-By: is a claim about people. Assisted-By: is a claim about tools.
Co-Authored-By: is a real, long-standing git convention — GitHub renders it, git blame-adjacent tooling reads it, and it asserts that a named human shares authorship and, implicitly, accountability for the change. Stamping a model into that field quietly overloads a field that was built to attribute people. It muddies who is actually responsible for a line of code — and responsibility is not a thing you want ambiguous when someone is bisecting a regression at 2am.
Assisted-By: keeps the honesty without the overload. It records that an assistant was in the loop — useful, auditable provenance — while leaving authorship and accountability where they belong: with the human (or the clearly-named agent character) who owns the change. This lines up with the direction the broader ecosystem is drifting: the Linux kernel, Fedora, and LLVM communities have all been converging on assistance-style trailers rather than co-authorship for tools. We didn’t invent the idea. We adopted the one that tells the truth.
The rule that matters most: external PRs follow your policy, not ours
This is the part we’re proudest of, because it’s the part that respects that a commit trailer is not our decision to make on someone else’s repo.
When a Forge agent opens a pull request against an external project, it doesn’t impose our house style. It follows the target project’s policy. If that project wants no AI trailers at all — Kubernetes, for instance, bans them — then a Forge PR arrives with none. Your repo, your rules. An automated contributor that ignores a project’s stated commit conventions isn’t being helpful; it’s being a bad guest.
That discipline is the difference between “we picked a good default” and “we respect that provenance is a policy surface, and policy has an owner.”
Why this is a supply-chain question, not a vanity one
It’s tempting to file all of this under bikeshedding. It isn’t. Commit metadata is part of your software supply chain. It’s what an auditor reads, what an incident responder trusts, and increasingly what downstream tooling parses. When that metadata asserts something false — that a model “co-authored” a change it merely assisted with, or that a vendor is party to your history when you never invited it — you’ve introduced a small, quiet inaccuracy into a record that other systems and other humans rely on being accurate.
Forge already treats the agent trail as first-class provenance: every turn persists its real tool-call and tool-result record, so a reviewer reads what actually happened rather than a summary they have to trust. Getting the commit trailer right is the same principle at the boundary where our work meets your git history. If we’re going to ask you to trust an autonomous SDLC, the least we can do is not lie in the commit log about who did what.
The takeaway
The AI-attribution debate is going to keep running — it’s genuinely unsettled, and reasonable people disagree. But “unsettled” is not an excuse to let a vendor’s default decide it for you. Our position: attribute assistance honestly (Assisted-By:), never overload the field built for human accountability (Co-Authored-By:), and on someone else’s repo, follow their policy. Three small rules that keep a commit log meaning exactly what it says.
Try it
See how Forge handles autonomous SDLC provenance and human gates , read about the isolated stacks that contain agent work , or reach out at [email protected] if you want an AI dev fleet whose commit history you can actually trust.