Is this a f**** joke? In your newest version, you now auto add Cursor as co-author to all git commits?? And not even allowing users to deactivate this??
Option 1:
Give clear infos/settings to turn this sh** off.
or
Option 2:
Be prepared for people to stop using Cursor and move to Claude Code and other services instead.
I have zero interest in constantly changing the commands, just because you don’t care about user consent and user interests.
So, fix this and never simply implement such functionalities without giving users the option to opt out!!
Steps to Reproduce
Instructing cursor to make a git commit.
Expected Behavior
A regular git commit, without adding co-authors. The way it used to work before.
@deanrie , I found this thread after noticing this sudden and poorly documented change. This is a change that should have been explicitly opt-in, not snuck in under the wire (based on my commit history, the behavior seems to have started today). Doing this sort of thing undermines customer trust in Cursor – I’m not sure what the underlying motivation here is, but it feels like a ham-handed attempt to pad the company’s engagement metrics.
It’s also very worrisome to suddenly see an additional ‘co-author’ added to a commit who’s not a member of an organization or private repo in Github. This could cause issues with security audits, automated monitoring, CI/CD systems or regulatory compliance for your customers.
@deanrie , thinking about this more, what Cursor has done here is very painful and inconsiderate. Firstly, your uninvited agent co-author ( cursoragent (Cursor Agent) · GitHub ) appears to be acquiring badges (“Pair Extraordinaire”) as a result of being added as a co-author to merged PRs.
Secondly, I now need to work out how to back out this unrequested co-authorship from a whole series of commits that have them. Reading https://stackoverflow.com/questions/3042437/how-can-i-change-the-commit-author-for-a-single-commit (to cite one example), this looks as if it’s going to be a painful process of amending each commit manually, rebasing, and then repeating the process for every affected commit. Not the way I wanted to spend my evening.
Would you please explain why Cursor chose to enable this behavior and change the default setting for this misguided “feature” to be disabled and opt-in only?
I agree that this change should have never been made to cursor. Who asked for this? Remember, developers are you customer. Focus on fixing bugs and building important features please… Not trying to advertise your product in git history
Cursor is in a very usable state. I appreciate the velocity, but you don’t have to treat users like beta users. You can afford polish things more now.
Agreed with OP. Just wtf is that? Default opt-in for this is really evil.
Had to waste my time to clean my commit history because of this BS.
I like Cursor but you guys have to realize we have alternatives and if you keep allowing yourself to screw your users (who pay hundreds per month) for no reason, we’ll leave.
We’ve already been kind enough to not leave after the huge pricing fiasco of 2025, but don’t test our patience too much.
I understand the “marketing” aspect, but who actually thought this could be a good idea? Thankfully I found out by browsing settings as I do after each update…
Personally, if I see this “marketing stunt”:
I do not think “oh wow lets try this tool as well”
I think “heh, this tool writes itself as a co-author, never gonna use it”
This feels like a Microsoft move. I can’t think of a single user who would ask for this or want this. If you want to keep internal metrics I don’t care but defacing my commit messages without opt in consent forcing me to spend time to undo your intentional ■■■■■■■ action… I understand when the models ■■■■ up but this is your update…
What the ■■■■ is going on? If any other tool starting costing me time and ruining an afternoon like this I would be instantly cancelling any subscription I might have, let alone a $200/pm one.
If another update you guys push, cause me this much of a ■■■■■■■ headache when I didn’t explicitly consent to the feature then I will never be using the product again. I cannot emphasis this clearly enough.
It’s one thing if agents are automatically working in the background and doing all this, but I am interactively driving cursor from the chat window, and if I ask it to create a commit, I don’t want your marketing slop in the commit message.
Incredibly inconsiderate. What else will Cursor sneak in our commits? That’s the question our team is asking atm, maybe others too (who have noticed, a lot will not notice).
This was a trust-damaging move guys. Might seem innocent “attribution”, but really? Did you need this so bad?
I’m currently using Cursor as my main editor, and often not using AI much at all, but also not infrequently use ‘plan’ mode and have entire large commits written in that way. Certainly wouldn’t want Cursor appearing as a contributor on every commit, and I’d find that pretty embarrassing if it’s on a PR to some open-source repo where the maintainer may take a dim view of such things.
I do, though, think it’s important to track provenance of changes made by AI vs human authors. In fact, I don’t think we have a viable means to do this properly just now, but if it’s done in the proper way I’d go so far as to say it should be difficult to opt-out of having this attribution.
If I’m debugging or reviewing some code, I want to know where it came from.
We understand that different users will have different preferences here. Some want to track AI-assisted contributions in their git history, while others prefer clean commit messages without any attribution.
That’s why this is configurable. As @deanrie mentioned, you can disable it under Agent > Attribution. We’ve also updated the docs to make it easier for users to find that config.
Don’t understand why everyone is so angry about this… why is it a problem? Do you want to hide the fact that you use AI coding tools?
You listed this “Firstly”, giving the impression this is your primary concern with this feature… I mean really, who cares?
I for one appreciate this feature so that we can see what impact use of Cursor is making on our codebase, and it would be helpful in identifying if poor use of AI tools are causing bad code to sneak in so we can correct it.
Sure, maybe a case can be made for making it opt-in rather than opt-out.
I like that it’s opt-in, that way I don’t need to tell everyone to turn it on. Also, I probably would have not found out about the feature were it not opt-in.
I guess it would have been nice if, for people like yourselves, they had a popup or something that asked you to opt-out if you didn’t want it when the feature was added.
Can you guys stop shipping features without taking feedback first? This should NOT be something to enabled by default just like almost all of the features that are coming into cursor these days.
I’m writing to provide feedback on the recent implementation of Git commit trailers/co-author metadata. It appears this feature was inspired by a specific community request (“How to nicely make Cursor to be commit co-author”), but that request had minimal community engagement. Implementing this as a silent, “opt-out” default has caused significant frustration for users who value clean, intentional Git histories.
To improve the relationship between the Cursor team and its power users, I ask that you adopt the following principles:
Prioritize Opt-In Design: For features that modify user data or metadata (like Git commits), the default should always be “Off.” Developers spend years refining their commit standards; tools should respect those standards unless explicitly invited to change them.
Provide Pre-Update Transparency: We need readable, detailed update logs before we commit to an update. If the team is too busy to document every change, I suggest using Cursor itself to generate these logs. We need to know exactly what is changing in our environment before the “Install” button is clicked.
Respect Workflow Stability: Many of us have spent countless hours configuring custom workflows, hooks, and rules. When updates are rolled out without clear documentation or opt-in toggles, they act like “live grenades” in our development environments. Unexpected changes don’t just add features; they blow up existing workflows and waste valuable billable time.
We love the speed of innovation at Cursor, but that innovation shouldn’t come at the cost of stability or developer autonomy. Please help us keep our workflows intact.
How to Remove Cursor’s Co-authored-by from Git Commits
Cursor automatically adds `Co-authored-by: Cursor [email protected]` to every commit message. You can only disable this in the IDE, but there’s no setting to disable this in the CLI, in Cursor cloud agents, or when using the “Generate git commit message” button.
You can remove it with a Git hook:
## Solution
Create a `prepare-commit-msg` hook that strips the line:
```bash
cat > .git/hooks/prepare-commit-msg << ‘EOF’
#!/bin/bash
sed -i ‘’ ‘/cursoragent@cursor\.com/d’ “$1”
EOF
chmod +x .git/hooks/prepare-commit-msg
```
**Note:** This uses macOS `sed` syntax. For Linux, use `sed -i` instead of `sed -i ‘’`.
## Linux Version
```bash
cat > .git/hooks/prepare-commit-msg << ‘EOF’
#!/bin/bash
sed -i ‘/cursoragent@cursor\.com/d’ “$1”
EOF
chmod +x .git/hooks/prepare-commit-msg
```
-–
The hook runs before each commit and removes any line containing the Cursor email. You’ll need to run this again if you clone the repo fresh (`.git/hooks/` is not version controlled).
