How to prevent Copilot Coding Agent from being the main author of commits in master

[alexander-jether]

Select Topic Area

Question

Copilot Feature Area

Copilot Coding Agent

Body

When I use the GitHub Copilot Coding Agent to implement features (New Agent Task button), it creates a pull request (e.g., master <- copilot/my_new_feature).
After reviewing and iterating on the PR, when I merge it to master using "Squash and merge" via the GitHub UI, the resulting commit author is set to Copilot rather than the person who requested the task.

This creates issues for my workflow:

• Git blame attributes the code to Copilot instead of the actual developer
• Contribution history doesn't accurately reflect who initiated and approved the changes
• Team accountability becomes unclear when reviewing commit history

What I need:
Is there a way to ensure that when merging Copilot-created PRs, the person who requested the work becomes commit author, while still acknowledging Copilot's contribution?

Ideal outcome:
Either the requester becomes the primary author with Copilot as co-author, or there's a configurable setting to control this behavior during merge.

Has anyone else encountered this issue? Are there any workarounds or best practices for maintaining accurate attribution when using Copilot Coding Agent?

[andriiafanasiev]

Right now, when you squash-and-merge a Copilot-created PR, GitHub sets the commit author to Copilot, which can mess up git blame and contribution history. A common workaround is to add a “Co-authored-by” line in the commit message so your name still shows. Another option is to amend the commit author locally after merging, but that’s more work for teams. It would be great if GitHub added a setting to let the requester be the primary author while keeping Copilot as co-author

[Sabari-Vasan-SM]

GitHub currently sets the commit author to “GitHub Copilot” because the Copilot Coding Agent creates the PR commits under its own identity. When you use Squash & Merge, GitHub keeps the author of the last commit — which ends up being Copilot.

There’s no automatic way today to make the requester the author.

Workaround

Before merging the PR:

Click “Squash and merge”

Click “Change author”

Select your GitHub user

(Optional) Add this to the commit message to credit Copilot:

[alexander-jether]

Thank you for response!
I don't see an option to "Change Author". Attached screenshot.

[Sabari-Vasan-SM]

GitHub only shows the “Change author” option when:

You are merging a PR from a fork, or

The PR contains commits authored by someone else AND you have write access

But GitHub Copilot PRs are created inside your own repository, so GitHub treats Copilot as you, and therefore hides the Change Author button.
That’s why you don’t see it in the screenshot.

✅ What you can do

Before clicking Squash and merge, edit the commit message and add:

"Co-authored-by: GitHub Copilot noreply@github.com"

This makes you the author, and Copilot the co-author, which is the closest available option today.

[alexander-jether]

This also didn't work, but thank you for the answer.

[rolaca11]

yo this thread feels like some copy pasted AI hallucination slop

1. There's no change author button
2. forgot to copy-paste the end of your AI response
3. Gemini gives the same hallucinated answer
4. pls remove the ✅ emoji. if you spam us with AI slop, at least try to hide it by removing the most glaring and obvious signs, or at least take the time to copy the chat window in markdown, so we see your chatbot in its full glory

[jsoref]

@queenofcorgis can you please explain to @Sabari-Vasan-SM that AI hallucinations aren't welcome in github community/community?

[jb-balaji]

I think there is no automatic way to fix the author, but manually update commit author: After merging, locally amend the author using git commit --amend --author="Your Name <you@email.com>" and force push git push -f .
Note: This can disrupt the PR merge trace in collaborative workflows.

[rolaca11]

I have an alternative idea. I haven't tried this yet, but in theory it should work:

1. You do your copilot vibe-coding thing how you were always doing it
2. When you're finished and are ready to merge, create a brand new branch from master, and open an empty PR manually
3. change Copilot PR's base to your new branch, and merge
4. now your branch should have every change from Copilot's branch
5. Merge your branch

This is a potential workaround, but tbh, GitHub should just get off their asses and do something about this. The limitations around Copilot and PRs feel arbitrary and unnecessary. Like the whole squashed commit author thing, or the fact that Copilot can only push changes to branches it made itself. Just get out of our way Github

[JT-Bruch]

Any potential updates here? Ideally it would be whoever opened the agent session. I'm finding it very hard to manage on my team who is working/coordinate on what with git blame because in all the IDEs it shows copilot not the person who initiated the change.

[jens-maus]

I fully agree here. IMHO when merging or squashing a PR which was spit out of a copilot session/agent it should contain the author that initiated the agent/copilot session as the main author of the PR rather than making Copilot itself the main author here. Would be great if this could be changed or being an option in the GitHub or Copilot setup UI...

[michael-proctor]

I have to agree, this has caused us a bit of grief as well, we have branch committer checks to ensure that the commits are using our domains to ensure cleanliness and attribution to who is doing changes.

The copilot agent using a random xxxxxxxxx-Copilot@users.noreply.github.com is hard to track.

Fun fact, we put in the instruction to change the email to one within our domain and the agent did actually do a git config command and changed the email.... the commit for the work did come from copilot@ourorg.com but the PR merge is still generated from the copilot identity.

it would be good if we could specify what email it should use or if we could use patterns like requestor-github-username+copilot@users.noreply.github.com so we have some way to link it back?

[nimra-tariq]

This is the most direct way to stop the behavior at the source.
VS Code:

• Open Settings (shortcuts: Ctrl+, on Windows/Linux or Cmd+, on Mac).
• Search for git.addAICoAuthor.
• Uncheck the box or set it to off.

Alternatively, add "git.addAICoAuthor": "off" to your settings.json

Worked for me.

[alnahian2003]

bro, you rock 🤘

[instantepiphany]

That is not what this discussion is about. This discussion is for the case where GitHub Copilot (running on GH servers, not on your machine) makes a code change based on your prompt. In that case, the only author of the commit is "copilot" - the person who asked copilot to make the change is not set as the author.

Your suggestion is for almost the opposite concern - when you use Copilot on your machine, e.g. via VS Code, a "Co-authored by copilot" line is added to the end of the commit message, unless you turn this setting off as you have described.

[ramkrishna757575]

Adding another angle to this same root problem which is usage attribution in copilot-setup-steps workflows.

We use a copilot-setup-steps.yml that tracks AI usage by calling an internal API to resolve which team member triggered the Copilot session. The intent is to attribute the session to the human developer who assigned the issue or started the task and not the bot.

Unfortunately, all of the standard workflow context variables resolve to copilot-swe-agent[bot] when Copilot triggers the workflow:

actor: copilot-swe-agent[bot]
triggering_actor: copilot-swe-agent[bot]
event sender: (empty)

This means there is currently no way to identify the human who initiated the session from within the workflow itself: not through github.actor, github.triggering_actor, the event payload, or any documented Copilot-specific environment variable.

This is the same underlying gap as the commit authorship problem described in this thread. The human who initiated the Copilot session is simply not surfaced anywhere in the workflow context.