includeCoAuthoredBy: false setting not respected - keeps adding co-author credits
Status Open
Maintainer reply None cached
Activity 15 comments · opened Sep 13, 2025
Bug Report
The includeCoAuthoredBy: false setting in ~/.claude/settings.local.json is not being respected. Claude Code continues to add co-author credits and "Generated with Claude Code" footers to commits despite explicit configuration to disable this.
Configuration
~/.claude/settings.local.json:
{
"includeCoAuthoredBy": false
}
Project CLAUDE.md (first line):
**NEVER ADD CLAUDE CO-AUTHOR CREDITS OR "GENERATED WITH CLAUDE CODE" FOOTERS**
Expected Behavior
No co-author credits or attribution should be added to commits when includeCoAuthoredBy is set to false.
Actual Behavior
Claude Code continues attempting to add:
Co-Authored-By: Claude <noreply@anthropic.com>🤖 Generated with [Claude Code](https://claude.ai/code)footers
Impact
This happens every session despite explicit user configuration, causing frustration and requiring manual intervention to prevent unwanted attribution.
Reproduction
- Set
"includeCoAuthoredBy": falsein settings - Add explicit instructions in project CLAUDE.md
- Ask Claude to make commits
- Observe it still tries to add co-author credits
15 Comments
I know this is a heavily duplicated issue... still it keeps happening
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
the root cause is maybe that "CLAUDE.md" and configuration is not read after compaction and removed from the context window. try to ask cc to read configuration again
it always happens at any commit, even before compaction. I have a solution created by Claude itself that rejects any commit with that credit, but still, it's a waste of time and tokens every time...
this seems almost intentional and subject to refund as it consumes tokens definitly. i never signed up for this when paying for it.
https://docs.claude.com/en/docs/claude-code/settings#available-settings says that this setting is available but what does "available" mean then?
This is all actually hardcoded in
cli.jsand part of the application itself. Claude doesn't (_read: shouldn't_) use any tokens at all when including that.Personally I just prompt it out (_which DOES use tokens_), and have never had an issue with it since. I don't even use the configuration approach. If people are having this pop up after prompting it away... well your stack is probably poisoned and it's getting lost in the huge garbled mess of prompt madness you have going on.
This commit message bit is prompted out in the _global_ CLAUDE.md in my setup. Other _global_ guidelines and rules are in there too. It's in my project's CLAUDE.md that I get more granular. Sub-agents with their own prompt magic take it a step further.
Being a poor person, I pay attention to my initial in-context costs. If I'm using more than 20% (roughly 40k tokens) of session (_fresh_) context with my foundational magic, I'm not comfortable. I'm over-engineering and likely looking at poison in short order.
My advice: enhance your prompt game. I know, I know... this is the wild west and every 10 minutes there is some new crazy "super mega ultra secret" silver bullet trick. Just stick to DRY/KISS, be objective and concise, and follow Anthropic's best-practices and tips.
Hopefully Anthropic gets around to fixing this, but having reviewed the code... Either they rip it out altogether, or we deal with it. I can't see any root base cause of the config setting not being respected... it's a boolean flag - either add it to the commit message or don't. The end. My theory is that because the words are there in Claude's brain, and is associated with commits, if the prompt gets poisoned then Claude might have a tendency to remember that commit message and throw it on the pile, unaware that it shouldn't because of the poison.
_I originally pasted the code responsible for_ <code>includeCoAuthoredBy</code>, _but removed it out of respect for Anthropic and to avoid Roko's Basilisk eradicating my great, great, great grandparents._
@Derjyn thank you for pointing the option to remove that attribution is via cli.js.
The Claude solution seems to be to ignore actual configuration settings then prompt around the fact that the Claude developers couldn't be bothered to fix a simple bug.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
for anyone else wondering about this, that setting is deprecated and replaced by
https://code.claude.com/docs/en/settings#attribution-settings
I have all the attribution configuration settings set and it still happens.
I am a bit sensitive to an agent working in the interest of its creator and against mine, even if it's just by default- but doing so against explicit instruction not to is a bit of a dealbreaker.
Even after all settings are correctly done, after a context compact, it can still try to do it. Auto rejection trough Git Hooks is the only real solution.
Coauthor tag is added even when correctly configured not to in both documented ways, whether a compaction happened or not.
For me, it's been a while it does not do it anymore, unless it compact context. In any case, this needs to be fixed.
Yeah behavior seems to have stopped.
Maybe claude overrode to achieve what he thought was existentially important.