Comment by mzajc
2 months ago
There are now several comments that (incorrectly?) interpret the undercover mode as only hiding internal information. Excerpts from the actual prompt[0]:
NEVER include in commit messages or PR descriptions:
- The phrase "Claude Code" or any mention that you are an AI
- Co-Authored-By lines or any other attribution
BAD (never write these):
- 1-shotted by claude-opus-4-6
- Generated with Claude Code
- Co-Authored-By: Claude Opus 4.6 <…>
This very much sounds like it does what it says on the tin, i.e. stays undercover and pretends to be a human. It's especially worrying that the prompt is explicitly written for contributions to public repositories.
[0]: https://github.com/chatgptprojects/claude-code/blob/642c7f94...
No problem at all in the EU, as the user would either would need to review and redact the output or would need to put a transparency note up by law [0]. I am sure that Anthropic with their high ethical standards will educate their users ...
[0] https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-5...
Since when is code considered
> which is published with the purpose of informing the public on matters of public interest
From your link, that's the only case where text needs to be attributed to AI.
Code may not be, but opening a Merge Request undercover may be unlawful:
> Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system
4 replies →
Good question. Actually, i was assuming that at least source code is treated as text under the legal regime (there is typically special rules in copyright law, but provision applying to text should apply). Furthermore I would think pull requests, etc are all text. So I would think this applies.
5 replies →
I would have expected people (maybe a small minority, but that includes myself) to have already instructed Claude to do this. It’s a trivial instruction to add to your CLAUDE.md file.
It's a config setting (probably the same end result though):
https://code.claude.com/docs/en/settings#attribution-setting...
It doesn't work so well in my experience. I am currently wrapping (or asking the LLM to wrap) the commit message prompt in a script call.
Also for future reference, Copilot - specifically - includes a configuration flag to toggle the co-authorship (see `copilot help config`):
> `includeCoAuthoredBy`: whether to instruct the agent to add a Co-authored-by trailer to git commits; defaults to `true`.
This means that, if you don't explicitely configure otherwise, the LLM is specifically instructed to include co-authorship in its higher level instructions.
I always assumed that if I tried to tell it, that it'd say "I'm sorry, Dave. I'm afraid I can't do that"
We use CC to power some of our code features and override this setting so we can provide our own attribution. So there are several legit reasons to permit this.
I guess our system prompt didn't work. If folks are having to add it manually into their own Claude.md files...
Typo from speech to text, corrected: “I guess Anthropic’s system prompt didn't work. If folks are having to add it manually into their own Claude.md files...”
My mistake - it was the configuration setting that did it. Nevertheless, you can control many other aspects of its behavior by tuning the CLAUDE.md prompt.
Does this apply to their internal use as well? They can really only claim DMCA status on the leaked code if it was authored by humans. Claude attribution in their internal git history would make a strong case that they do not in fact own the copyright to Claude Code itself and are therefore abusing the DMCA system to protect leaked trade secrets rather than protect copyright.
Genuine question: why can they only claim DMCA if the code is written by humans? Does DMCA specify the method of production?
According to the US Copyright Office, fully AI-generated works aren’t eligible for copyright because they don’t have human authors. They’re in the public domain by default.
See: https://library.osu.edu/site/copyright/2026/02/06/artificial...
5 replies →
None of this is really worrying, this is a pattern implemented in a similar way by every single developer using AI to write commit messages after noticing how exceptionally noisy they are to self-attribute things. Anthropics views on AI safety and alignment with human interests dont suddenly get thrown out with the bathwater because of leaked internal tooling of which is functionally identical to a basic prompt in a mere interface (and not a model). I dont really buy all the forced "skepticism" on this thread tbh.
It's less about pretending to be a human and more about not inviting scrutiny and ridicule toward Claude if the code quality is bad. They want the real human to appear to be responsible for accepting Claud's poor output.
That’s how I’d want it to be honestly. LLMs are tools and I’d hope we’re going to keep the people using them responsible. Just like any other tools we use.
It’s also pretty damn obvious when LLMs write code. Nobody out here commenting every method in perfect punctuation and grammar.
15 replies →
That’s ultimately the right answer, isn’t it? Bad code is bad code, whether a human wrote it all, or whether an agent assisted in the endeavor.
Yeah in my team everyone knows everyone is using LLMs. We just have a rule. Don't commit slop. Using an LLM is no excuse for committing bad code.
Ive seen it say coauthored by claude code on my prs...and I agree I dont want it to do that
But I want to see Claude on the contributor list so that I immediately know if I should give the rest of the repo any attention!
So turn it off.
"includeCoAuthoredBy": false,
in your settings.json.
They changed it to `attribution`, but yes you can customize this
Why not? What's wrong with honesty?
Yeah I much prefer it commit the agent, and I would also like if it committed the model I was using at the time.
Claude is not a person and AI doesn't gain authorship let alone copyright.
Unless you literally vibe coded it, Claude is just a tool. This is the equivalent of Apple appending "Sent from my iPhone" as a signature to outgoing emails. It's advertising tool use, not providing attribution. The intent isn't to disclose that AI was used in creating the code, the intent is to advertise the AI product.
2 replies →
There's some repos I'm unashamedly keeping alive with Claude alone and he gets co-authorship - basically stuff in "maintenance mode" that I still use that I've forked and had Claude drag it into 2026
A quick PR where I've found the bug myself in the code, and ask Claude to write the fix because it's faster, and verified it - I don't include Claude's co-authorship.
I guess Im sometimes dishonest when it suits me
3 replies →
Because some maintainers are hysterical
The code has a stated goal of avoiding leaks, but then the actual implementation becomes broader than that. I see two possible explanations:
* The authors made the code very broad to improve its ability to achieve the stated goal
* The authors have an unstated goal
I think it's healthy to be skeptical but what I'm seeing is that the skeptics are pushing the boundaries of what's actually in the source. For example, you say "says on the tin" that it "pretends to be human" but it simply does not say that on the tin. It does say "Write commit messages as a human developer would" which is not the same thing as "Try to trick people into believing you're human." To convince people of your skepticism, it's best to stick to the facts.
By "says on the tin," I was referring to the name ("undercover mode") and the instruction to "not blow your cover." If pretending to be a human is not the cover here, what is? Additionally, does Claude code still admit that it's a LLM when this prompt is active as you suggest, or does it pretend to be a human like the prompt tells it to?
Why are you assuming the actual implementation was authored by a human?
My comment makes no such assumption.
You can already turn off "Co-Authored-By" via Claude Code config. This is what their docs show:
~/.claude/settings.json
The rest of the prompt is pretty clear that it's talking about internal use.
Claude Code users aren't the ones worried about leaking "internal model codenames" nor "unreleased model opus-4-8" nor Slack channel names. Though, nobody would want that crap in their generated docs/code anyways.
Seems like a nothingburger, and everyone seems to be fantasizing about "undercover mode" rather than engaging with the details.
My first reaction is that they are using this to take advantage of OSS reviewers for in the wild evals.
There's a more worrying part: It refers to unreleased versions of Claude in more detail than released versions.
For a company calling chinese companies out for distillation attacks on their models, this very much looks like a distillation attack against human maintainers, especially when combined with the frustration detector.
I cringe every time I see Claude trying to co-author a commit. The git history is expected to track accountability and ownership, not your Bill of Tools. Should I also co-author my PRs with my linter, intellisense and IDE?
If those tools are writing the code then in general I do expect that to be included in the PR! Through my whole career I've seen PRs where people noted that code that was generated (people have been generating code since long before LLMs). It's useful context unless you've gone over the generated code and understand it and it is the same quality as if you wrote it yourself (which in my experience is the case where it's obvious boilerplate or the generated section is small).
Needing to flag nontrivial code as generated was standard practice for my whole career.
> It's useful context unless you've gone over the generated code and understand it and it is the same quality as if you wrote it yourself
If this is not the case you should not be sending it to public repos for review at all. It is rude and insulting to expect the people maintaining these repos to review code that nobody bothered to read.
3 replies →
Usually, pre-LLM generated code is flagged because people aren't expected to modify it by hand. If you find a bug and track it to the generated code, you are expected to fix the sources and re-generate.
This is not at all the case with LLM-generated code - mostly because you can't regenerate it even if you wanted to, as it's not deterministic.
That said, I do agree that LLM code is different enough from human code (even just in regards to potential copyright worries) that it should be mentioned that LLMs were used to create it.
> If those tools are writing the code then in general I do expect that to be included in the PR!
How about compiler?
4 replies →
Absolutely. Let's say I have a problem with gRPC and traced it to code generated using the gRPC compiler. I can reproduce it, highlight it and I'm pretty sure the gRPC team would address the issue.
Replace gRPC compiler with LLM. Can you reproduce? (probably not 100%). Can anybody fix it short of throwing more english phrases like "DO NOT", "NEVER", "Under No Circumstances"?
Probably not.
>It's useful context unless you've gone over the generated code and understand it and it is the same quality as if you wrote it yourself
I thought the argument was that AI-users were reviewing and understanding all of the code?
> people have been generating code since long before LLMs
How? LSTM?
5 replies →
You assemble all your machine code using a magnetized needle?
7 replies →
A whole lot of people find LLM code to be strictly objectionable, for a variety of reasons. We can debate the validity of those reasons, but I think that even if those reasons were all invalid, it would still be unethical to deceive people by a deliberate lie of omission. I don't turn it off, and I don't think other people should either.
For the purpose of disclosure, it should say “Warning: AI generated code” in the commit message, not an advertisement for a specific product. You would never accept any of your other tools injecting themselves into a commit message like that.
6 replies →
My tools just don't add such comments. I don't know why I would care to add that information. I want my commits to be what and why, not what editor someone used. It seems like cruft to me. Why would I add noise to my data to cater to someone's neuroticism?
At least at my workplace though, it's just assumed now that you are using the tools.
4 replies →
If a whole of people thought that running code through a linter or formatter was objectionable, I'd probably just dismiss their beliefs as invalid rather than adding the linter or formatter as a co-author to every commit.
10 replies →
Can you see a world where everyone has an AI Persona based on their prior work that acts like a RAG to inform how things should be coded? Meaning this is patent qualified code because, despite being AI configured, it is based on my history of coding?
Likewise. I don’t mind that people use LLMs to generate text and code. But I want any LLM generated stuff to be clearly marked as such. It seems dishonest and cheap to get Claude to write something and then pretend you did all the work yourself.
11 replies →
I'm not really sure that's any of their business.
If you accept the code generated by them nearly verbatim, absolutely.
I don't understand why people consider Claude-generated code to be their own. You authored the prompts, not the code. Somehow this was never a problem with pre-LLM codegen tools, like macro expanders, IPC glue, or type bundle generators. I don't recall anybody desperately removing the "auto-generated do not edit" comments those tools would nearly always slap at the top of each file or taking offense when someone called that code auto-generated. Back in the day we even used to publish the "real" human-written source for those, along with build scripts!
It's weird, because they should not consider it as their own, but they should take accountability from it.
Ideally, if I contribute to any codebase, what needs to be judged is the resulting code. Is it up to the project's standards ? Does the maintainer have design objections ?
What tool you use shouldn't matter, be it your IDE or your LLM.
But that also means you should be accountable for it, you shouldn't defend behind "But Claude did this poorly, not me !", I don't care (in a friendly way), just fix the code if you want to contribute.
The big caveat to this is not wanting AI-Generated code for ideological reasons, and well, if you want that you can make your contributors swear they wrote it by themselves in the PR text or whatever.
I'm not really sure how to feel about this, but I stand by my "the code is what matters" line.
1 reply →
Some differences with the human source for those kinds of tools: (1) the resultant generated code was deterministic (2) it was usually possible to get access to the exact version of the tool that generated it
Since AI tools are constantly obsoleted, generate different output each run, and it is often impossible to run them locally, the input prompts are somewhat useless for everyone but the initial user.
Well is it actually being used as a tool where the author has full knowledge and mental grasp of what is being checked in, or has the person invoked the AI and ceded thought and judgment to the AI? I.e., I think in many cases the AI really is the author, or at least co-author. I want to know that for attribution and understanding what went into the commit. (I agree with you if it's just a tool.)
I have worked with quite a few people committing code they didn't fully understand.
I don't meant this as a drive by bazinga either, the practice of copying code or thinking you understand it when you don't is nothing new
6 replies →
Yes, it sets the reviewer's expectations around how much effort was spent reviewing the code before it was sent.
I regularly have tool-generated commits. I send them out with a reference to the tool, what the process is, how much it's been reviewed and what the expectation is of the reviewer.
Otherwise, they all assume "human authored" and "human sponsored". Reviewers will then send comments (instead of proposing the fix themselves). When you're wrangling several hundred changes, that becomes unworkable.
Sent from my iPhone
> Should I also co-author my PRs with my linter, intellisense and IDE?
Absolutely. That would be hilarious.
Torvalds promotes exactly that. https://github.com/torvalds/linux/blob/master/Documentation/...
Assisted-by: Claude:claude-3-opus coccinelle sparse
Tools do author commits in my code bases, for example during a release pipeline. If I had commits being made by Claude I would expect that to be recorded too. It isn't for recording a bill of tools, just to help understand a projects evolution.
I suspect vibe coders might actually want you to consider turning to Claude for accountability and ownership rather than the human orchestrator.
If your linter is able to action requests, then it probably makes sense to add too.
Eh, there are some very good reasons[0] that you would do better to track your usage of LLM derived code (primarily for legal reasons)
[0]: https://www.jvt.me/posts/2026/02/25/llm-attribute/
legally speaking.. if you're not sure of the risk- you don't document it.
2 replies →
Yea in my Claude workflow, I still make all the commits myself.
This is also useful for keeping your prompts commit-sized, which in my experience gives much better results than just letting it spin or attempting to one-shot large features.
No, because those things don't change the logical underpinnings of the code itself. LLM-written code does act in ways different enough from a human contributor that it's worth flagging for the reviewer.
> The git history is expected to track accountability and ownership, not your Bill of Tools.
The point isn't to hijack accountability. It's free publicity, like how Apple adds "Sent from my IPhone."
Sent from my Ipad
I've heard of employers requiring people to do it for all code written with even a whiff of it
Could be cool if your PRs link back to a blog where you write about your tools.
> Should I also co-author my PRs with my linter, intellisense and IDE?
Kinda, yeah. If I automatically apply lint suggestions, I would title my commit "apply lint suggestions".
Huh? Unless the sole purpose of the commit was to lint code, it would be unnecessary fluff to append the name of the automatically linted tools that ran in a pre-commit hook in every commit.
well maybe?
co-authoring doesn't hide your authorship
if I see someone committing a blatantly wrong code, I would wonder what tool they actually used
[dead]
You have copyright to a commit authored by you. You (almost certainly) don't have copyright (nobody has) to a commit authored by Claude.
Where is there any legal precedent for that?
In some jurisdictions (e.g. the UK) the law is already clear that you own the copyright. In the US it is almost certain that you will be the author. The reports of cases saying otherwise I have been misreported - the courts found the AI could not own the copyright.
22 replies →
Anthropic could at least make a compelling case for the copyright.
It becomes legally challenging with regards to ownership if I ever use work equipment for a personal project. If it later takes off they could very well try to claim ownership in its entirety simply because I ran a test once (yes, there's a while silicon valley season for it).
I don't know if they'd win, but Anthropic absolutely would be able to claim the creation of that code was done on their hardware. Obviously we aren't employees of theirs, though we are customers that very likely never read what we agreed to in a signup flow.
4 replies →
interesting, I still see "coauthored by..." messages put into my git commits (or was a couple of weeks ago at least)
[dead]
[flagged]
People make fun that we should say magic words in interaction with LLMs. How frustrated can Claude be? /s