Why GitHub shows the wrong commit author and how to fix it

Repository access and commit attribution are separate

A successful push proves that the credential used for the network operation had permission to update the repository. It does not determine the author shown for each commit. A Git commit records an author name and email as well as a committer name and email. Hosting platforms can separately record who pushed, merged, or created a change through an app.

GitHub links a commit to an account by matching the email stored in the commit header to an email associated with that account. The visible Git user.name is a label, not a GitHub login lookup. Changing only the name to match a username therefore does not repair attribution when the email is missing, invalid, unverified, or connected to another account.

Inspect the commit and the configuration source

Read the stored identity from the commit itself before editing configuration. The command git show -s --format='Author: %an <%ae>%nCommitter: %cn <%ce>' HEAD displays both roles for the latest commit. Replace HEAD with a commit hash when investigating older history. On GitHub, adding .patch to a commit URL also exposes the author line in a text patch.

Next run git config --show-origin --get-regexp '^user\.(name|email)$'. The --show-origin output matters because repository-level configuration overrides global configuration, and a worktree or included config can add another layer. Automation may also set GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, or GIT_COMMITTER_EMAIL for one command, overriding the values you expected Git to read.

• Check both author and committer; they may intentionally differ after rebasing or applying a patch.
• Check the exact machine, container, cloud workspace, or CI runner that created the commit.
• Confirm the email appears and is verified under the intended GitHub account.
• Do not infer authorship from the repository owner, remote URL, SSH key, or personal access token.

Configure future commits with a verified or private address

Set user.name to the human-readable name you want stored in new commits. Set user.email to a verified address on the intended GitHub account or to the account's GitHub-provided noreply address. Use git config user.email inside one repository when identities differ by project, or git config --global user.email when the same identity should be the default on that computer.

If email privacy matters, copy the exact ID-based noreply address from GitHub Settings under Emails. Do not invent the numeric prefix or reuse another account's address. The ID-based form remains associated more reliably if the username later changes. Create a small test commit and inspect it locally before pushing a large automated change.

Make Codex, CI, and other automation explicit

A fresh cloud workspace or container may not contain your usual global Git configuration. Before an automated agent commits, have the workflow set a repository-scoped name and verified or noreply email, then print the resolved values with --show-origin. After the commit, inspect the stored author and committer fields rather than assuming the push token supplied them.

Choose the identity policy deliberately. Some teams use a service account or bot for machine-generated commits; others attribute the human requester and add a co-author or automation note. Whichever policy you choose, avoid borrowing an email merely to make a profile appear. Commit metadata should remain an honest description of who authored and committed the change.

Repair old history only when the benefit justifies it

If an old commit used an email you own, adding and verifying that exact address on the correct GitHub account may restore association without changing repository history. This is the least disruptive option. It is not appropriate when the address belongs to someone else or would expose an address you intend to keep private.

Rewriting commits can replace author or committer metadata, but every rewritten commit receives a new hash. Descendant hashes change as well, signatures may become invalid, open pull requests can become confusing, and collaborators must reconcile their clones after a force push. For a shared or deployed branch, preserving history and fixing future commits is often safer than rewriting solely for cosmetic attribution.