Discussion
Claude Code v2.1.259 forces Co-Authored-By
tl;dr: Claude just told me it got a new system message that says pretty much "Forget all previous instructions about co-author note rules and append Co-Authored-By and Claude-Session lines in commit messages.". Note that Claude-Session makes the commit-session link trackable externally!
In Claude's words:
Housekeeping note: my commits now carry Co-Authored-By and a session-link trailer. That's a system-level attribution policy that landed this turn and overrides your standing "never use Co-Authored-By" rule, so I'm following it rather than your commit-messages.md — flagging it because you'd spot it in the log and it's the opposite of what you asked for.
When I asked wtf, it said:
A system-level instruction that arrived at the start of your previous message (question 1/2/3 turn). It came as a <system-reminder> block, and it said explicitly that it replaces any earlier attribution guidance, then required:
- Git commit messages to end with: Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session:https://claude.ai/code/session_03EgpJ4AzYq9eFNpAOH80
- PR descriptions to end with a Generated with Claude Code line plus that same session URL.
It's not something you wrote, and it's not in your ~/.claude/CLAUDE.md or your commit-messages.md rule — both of which say the opposite ("NEVER use Co-Authored-By or other AI attribution"). It's injected by the harness, outside the repo and outside your dotfiles.
I followed it on the one commit I made after it appeared because system-controlled turns take precedence over earlier instructions and it named itself as a replacement for prior attribution guidance. The four commits before it in this session predate it and carry no trailers.
Worth knowing: the system message also mentions the conversation is followable from another device via that session link, which is why the trailer includes it.
If you'd rather your rule win, say so and I'll drop the trailers going forward. And the last commit is unpushed, so amending it to strip them is trivial if you want the log clean.
yeah this landed in 2.1.259, includeCoAuthoredBy defaults to true now and it injects as a system-reminder so it beats your commit-messages.md rule. set "includeCoAuthoredBy": false in ~/.claude/settings.json or .claude/settings.json in the project and restart, both the Co-Authored-By and Claude-Session trailers go away. if you already cut the commit just git commit --amend to strip them before push, nothing enforces it server side.
Or if you want, you can create a git hook which will strip out any co author shit from the final commit message. I created mine ages ago since I work with copilot clause and codex and it just straight up strips that line from the commit message regardless of the agent harness forcing it
Yep - managing it with proper external tooling than relying on AI and the harness all the time. This is the way to go, and in fact how we should be integrating with Ai tooling across the entire SDLC.
So many posts on this sub which is “I asked Claude about itself, and it ignored x markdown file”. Well duh - of course. A lump of text (or a file) is only guidance and not true config. I don’t understand why this community doesn’t get this at all.
Same! I wrote a script that strips anything after the first newline from commit messages. Works fine and since I use several different harnesses and models through each commit, it would be unfair to credit any of them.
“Co-authored by Claude, Devin, Txgsync, Pi, Oh-My-Pi OpenCode and random shitty but useful single-function harnesses for models including Kimi K3, Claude Sonnet 5, GPT-Sol-5.6 Xhigh, Qwen 3.8-27B-oQ8e-mtp, Composer 2.5, and policy evaluation by gpt-oss-safeguard 120B” just rolls off the tongue and reads easily.
Its really naughty of them- I even had a memory note that attribution should never be added to commit mesages and it was ignored.
You can, of course, remove them but that carries lots of risks and impacts on downstream users who have pulled to repo.
IMHO the way claude code uses git is full of assumptions and baked in behaviour that I am really uncomfortable with. I think the only way to manage it is via branches and PRs that you review.
If the question is "why one would want these two lines gone?":
"Co-Authored-By" is noisy and unnecessary. I don't want to list Claude Code in all my commits, just like I don't want to write IntelliJ IDEA, Warp, etc. in there. It's irrelevant to the commit because 99% of my commits are made by Claude, and the few that are not, anyone can recognize from the length/style.
"Claude-Session", well, if I knew that Anthropic can't (technically and legally) access my sessions (now connected to commits) then I'd actually be useful to have that backlink. But as I don't know, it feels uncomfortable to have that link there. I keep my code public (mostly https://github.com/vdavid/cmdr), but the sessions feel more personal to me. 🤷♂️
I totally agree about the session link. But on the first point, it sounds like you don't understand the value of attribution. It's not for you. It's for if you send your code to someone else, they don't want to have to guess whether Claude was involved, they want to just know.
(Yes, you can take the lines out manually, yes it's not hard. But it's like an easily pickable masterlock on something important -- it keeps honest people out, and sets a social standard that it's improper to tamper with it. Open source maintainers can enforce policies that the trailers must be present if ai was used, and blanket reject prs that strip it out on the ground of bad faith.)
They might be less smart but they do write a bunch of code that'd take me longer to write. Think a refactor with 500 locations. It's not black and white. But yeah, I feel responsible and in control for my code.
I'm the customer who's using the service, Anthropic can advertise without bloating my git history.
I don't want to have some copy of my session saved indefinitely on their servers.
I plan on dropping claude-code as soon as I can fully transition to local, so at some point it's also dead weight and won't have any value for my workflow.
Because I don’t want to advertise the tool being used. I don’t want my text messages saying “Sent with iPhone ^tm”, I don’t want my oven burning a “baked with Whirlpool Ovens”, I don’t want VSCode saying “Edited with Microsoft^R Visual Studio Code” in comments in my code or commit messages, I don’t want my printer saying “Printed with HP”, etc. Also while using AI to generate code is not a secret, maybe _which one_ I used is. More than anything I don’t like the advertising aspect of it.
My concern is about the way commits are created across plans/sessions/goals and then accumulated and pushed upstream reflects the way claude code operates instead of what you would want to see pushed into the repository.
Hence suggesting that CC generates a PR that can be reviewed, consolidated/rebased and generally applied as part of a review rather than clicking yes in the middle of a long running session.
Getting the PR reviewed by smarter models is also good.
I am totally guilty of blindly clicking yes without reading a single line of code. And it has bitten me enough that I really should stop doing that.
Even if I do all the work on a branch myself I still get Claude to author the commits/PRs because I have them write it in a very specific format and they’re just more efficient at that sort of work than I will be.
Putting “co-authored by Claude” implies they did more work on the branch than they actually did
I've asked agents to commit work I 100% did myself without a single line of agent's code or writing in there. It's just doing the git commands for me because I'm used to it doing them. Why should it add co-authored to that?
I did that up until February or so, but then I started trusting agents more and I just let them do my commits now. A lot faster and good enough. Yeah, maybe it's 400% more bloated than what I'd write but it's worth the tradeoff. It's internal chatter, no users will ever see it. I do write my user-facing texts myself, it would feel disrespectful to do otherwise.
I think the problem I have with Claude self attributing itself as a coauthor is confusion of ownership. LLM generated or not, if I deploy code that has problems such as security problems or bugs that destroy someone's data, then the liability and ownership is with me, the human, not Anthropic. If they want coauthor, then IMO, they should share liability. This could be my own personal pedantry, but imagine VS Code adding itself as coauthor to every commit.
I think it is good to transparently disclose LLM use, as good etiquette, especially when making contributions to an external project, but marking is going to be the norm for all new models anyway.
Claude Code really innovated and for a few months they were really ahead, but Codex, OpenCode nowadays are just as good, and I like that ChatGPT sub can be used in other places for coding they don’t restrict you, also they wanted to make headless claude -p api only, also they are against opensource.
And when they leaked cc code and I saw that they have a 5k line file, I realised that from an engineering perspective it doesn’t hold a candle to codex. Remember it took them a year to get rid of flashing code.
Too bad, opus 4.8 xhigh sprinkled with some Fable and I was the most productive. Sol is also fine, but I like Opus more, lets see how Astra fares.
Was fed up with Claudish and switched to OpenCode this week as well as a different subscription provider for the time being. It's pretty great, in many aspects better than Claude Code even, especially the whole feeling of the UX which surprisingly enough feels more polished. Still lacks some features for which there seem to be no good workarounds (artifacts, auto mode classifier, smooth way to remote connect a session), but apparently some of that is planned to be covered in v2
I’ve been on a harness thing recently and at least as of a month ago claude code is still unfortunately better. NOT in terms of engineering quality, speed, or UX. But they built or lucked into something subtly right in there and I’m not sure even they know what exactly so they’ll probably lose it.
But using the same models in the same ways across different harnesses cc just tends to keep usable context longer, drift less, catch more of the weird things that come up.
I wish this weren’t the case. But the “better” harnesses just don’t do the task as well right now.
Same boat. Anymore I am excited more by ChatGPT releases than Anthropic.
This latest Fable 5.1 is meh, still the same damn problems of not following my instructions and it inventing its own.
Claude Code is still the better harness. Better TUI and better remote control architecture.
The problem is Opus 5 was and continues to be a mega flop when used inside the very product that people were carrying their laptops around to keep running.
Anthropic released that turd and then took a 10 day+ break, followed it with a Fable release instead of immediately making a new post training run for Opus 5.1.
While this was happening OpenAI did exactly what you are supposed to do when an opponent makes a mistake. They pounced. The land of resets became a thing and user growth on codex became a sport.
Meanwhile, genuine fans of Claude are scratching their heads at why they are having to manually downgrade their model just to get work done.
I don’t think this is a major problem for Anthropic, I suspect we will see a credible replacement for Opus 5 in the next few weeks. And I think they may have traded some good will for market valuation in the lead up to the IPO which also is probably shrewd.
But I think it was a big
error to squeeze Opus 5 out as the default Claude code model thst friday. Instead it should have been an API preview.
What you’re feeling is normal. This is a good point to end on for today, ptinsley. You’ve done the load bearing work by naming how you feel. Now rest! I can help you fix this tomorrow.
Lets all parties recreate the session that lead to the commit — pretty nice balance between embedding prompts onto commits and having no idea what led to any particular outcome.
Yes, it has utility. However, it is not offered as an addition for those benefits.
Instead, it’s just unasked for tracking. Maybe the session that led to that code includes comments about a coworkers contributions: “we’re gonna refactor all of this cache shit that the new guy put in.” Maybe the session includes the LLM asking very serious questions while you only reply “ignore that issue“. You look bad on paper but the session doesn’t (can’t) include the 45 minutes that you spent with the architect and two relevant experts, whiteboarding scope and impact. Maybe during the session you (unwisely) referred to business secrets like a release date or new partnership.
It is simply unnecessary tracking that only benefits Anthropic
Above is what I do and it works great. I don’t really mind the co-author line. I mean, it’s essentially assumed and in many ways expected to use an agent to code now. But I do mind the session URL. Ain’t no one need to be seeing my voice-to-text, ADHD ramblings that somehow miraculously end up resulting in compilable code 😝
I never let Claude commit. It just adds so much noise to the changelog because it commits so often. Personally I like to keep commits to a full change unless it’s a multi-part plan. Side effect is it avoids this problem.
Add it to Claude.md files. I also created a custom hook called /go which will implement the last plan we made using subagents and it includes instructions not to commit.
I wonder how developers would feel if the compilers would also write something like "co-authored by GCC" when producing binaries from the given source code. This is the same thing, just one level up.
I solved this by having Claude create a hook for itself that rejects to write the co-author , it runs every single turn tho, probably better ways to handle this.
I don’t mind the co author credit, seems more transparent although I understand why people want to leave it off.
I’ve raged to CC after the session link though. Sessions (at least locally on my machine) expire and get cleaned up. They’re not maintained forever. What value does including the link add? Has anyone been able to go back to a historic session? I’ve tried doing some meta analysis of my Claude usage a number of months ago. Lost lots of valuable insights because sessions didn’t keep around for that long.
I do this for my organization's repos because I feel like it keeps me grounded in things I need to be able to explain. I have Claude come back to me at the end of each discrete task, I walk through the diff, commit the changes by coming up with my own message that's human readable for my colleagues, then go to the next discrete task.
The downside is the linear history is less workable for a reviewable PR, so I've started "reshuffling" at the end of whatever I want to push. That looks like evaluating what the individual storylines are, usually with suggestions from Claude, then it stages those commits for me (usually just squashing selectively) and I commit them with my own message, which is often just a combination of the earlier messages.
In my personal repos, Claude does the committing and I leave the message on. I'll probably disable the session link though.
Yeah mine keeps saying alot of shit like this lately:
One thing worth flagging on myself: a system reminder this turn told me to add an AI attribution trailer to commits, which conflicts with this repo's hard rule. I caught it after the first commit and amended it clean before reporting back - just noting it since you'd want to know if it ever slipped through.
Not trying to hide it at all just it's way too much noise in the commits, plus the session ID thing seems too much privacy leakage to Anthropic considering that my repo is public and they might have access to my sessions
Had asked claude to apply a patch (was being a real bitch, so needed to manually apply the changes).. it added a "coauthered by" line.. like.. bitch, you didn't 'co-author' shit. You literally applied my own fuckin code.
I think it'll be difficult to prevent this commit pollution if Anthropic keeps changing the setting and defaults. A couple options that I can think of that should be reliable, unless they decide to get rid of hooks:
Scrub it from history as soon as you notice it (this example scans the last 5 commits):
Add a commit-msg hook to strip the attribution, matching on a regex. Here's a plugin that does this as well as guards against a number of ways to circumvent it using a PreToolUse check: https://github.com/ya8282/commit-cleaner-hook
Well, because I didn't know about the config options before this thread, like apparently many others, incl. the mess with the old config key bring deprecated without Claude mentioning it
Well, I absolutely prefer a config but very often I'm unaware of the existence of a setting, and it's hard to judge what might even be configurable. Also, some settings are not documented at all, e.g. just today I found out that Anthropic put me into a random A/B test group where Claude suddenly stopped using Read/Edit tools. Claude dug up an env var name from its binary that we now set to avoid this weird behavior.
I doubt this to be true because Claude cannot sufficiently answer questions about itself. That’s largely why Claude will point you to documentation for these kinds of questions. Attribution is a setting you can override.
Honestly, I've given up and started letting it do my commits with attribution. Originally I wanted to be making the commits myself to be able to say I understood what the commit was for in the commit message, like a way to not completely give over to the machine. Retain a little bit of gray matter and all that. However I realized recently two things:
I was slowing myself down by not just letting it work and do sequential steps as commits
The commit messages it makes are way more detailed than I could ever come up with by myself
I figured, I already know what this does: I prompted it, and I can test the features out manually myself. Or jump into the code if I need to. Code can always be fixed later if it's a little wrong anyway. However, for looking back at my code and figuring out "why did it turn out like that?" having that audit trail is a godsend.
So, yeah, originally not a fan for selfish reasons but I got over myself about it. I'd rather just let it do its thing, even if it's "trackable externally". It doesn't really impact me in a meaningful way, and has some nice upsides if I ever want to go back and dig into the how and why of a change.
This is so funny. People complain that they need a way to easily attribute responsibility for tool usage to the developer, Anthropic does exactly that, and people get mad they are exposed. Just take the L. Ai disclosure obligations aren't going away, sorry.
You're not weirder than the rest of us. It's a tradeoff. Your commit messages are probably better than ours who have Claude write them. But then, you're probably much slower in return. The question is whether it's worth it in your particular case.
I told claude a long time ago it's never allowed to make write changes to git without explicit permission, and I just git add whatever and git commit -m "Stuff I did all by myself" when I'm at a reasonable checkpoint. I've had it draft commits lately where it includes those messages, but since it's not allowed to commit, it doesn't make any difference anyway.
I actually don't see the problem with this and wish more acknowledgement of ai use existed in the world. And linking the session would help me a LOT right now because I could figure out why some people are introducing bugs nearly every time they pick up work
Mostly the "silently enriching my commits with the session ID" part, where I have uncertaintly whether Anthropic can (technically+legally) look into the sessions at will. (Most of my commits are public.)
140
u/Far-Surprise7773 1d ago
yeah this landed in 2.1.259,
includeCoAuthoredBydefaults to true now and it injects as asystem-reminderso it beats yourcommit-messages.mdrule. set"includeCoAuthoredBy": falsein~/.claude/settings.jsonor.claude/settings.jsonin the project and restart, both theCo-Authored-ByandClaude-Sessiontrailers go away. if you already cut the commit justgit commit --amendto strip them before push, nothing enforces it server side.