VS Code Now Credits Copilot on Every Commit by Default

There's a one-line pull request open against microsoft/vscode. It changes the default value of a setting called git.addAICoAuthor from "off" to "all". The PR is titled, with no embellishment, "Enabling ai co author by default." It was opened on April 15, 2026 by cwebster-99, a member of the VS Code team. By the time the HN thread on the PR hit 1,239 points and 646 comments in early May, the practical effect was already shipping: every commit you make in VS Code, regardless of whether you wrote the code yourself or had Copilot write it, gets a Co-authored-by: Copilot trailer in the commit message.

The setting value "all" is not a misnomer. It literally means: add the trailer to all commits. The HN poster's headline framing — "regardless of usage" — is operationally accurate. If you don't change the setting, every commit your IDE produces credits Copilot in writing.

The bug Copilot's own AI review caught

The most peculiar artifact inside the PR is the Copilot code-review comment, generated by GitHub's own Copilot Pull Request Reviewer service. It noticed something the human author didn't: the schema default in extensions/git/package.json was changed to "all", but the runtime fallback in extensions/git/src/repository.ts still calls config.get('addAICoAuthor', 'off'). The two are now out of sync. The AI's own review comment, in the PR's own review thread, names the failure mode in unusually clear language:

"This is now out of sync and can lead to unexpected behavior in contexts where the contributed configuration defaults aren't loaded (e.g., some tests/hosts), and it makes the intended default unclear."

So the trailer is on by default in the schema. The trailer is off by default in the runtime fallback. Which one wins depends on the load path of the configuration in the specific VS Code host. In a normal user-facing VS Code session, the schema default wins; in some tests and embedded hosts, the runtime fallback wins. The Copilot AI's own catch is the most precise description of the "regardless of usage" problem in the entire PR review: the default behavior is now unpredictable across launch contexts.

The PR has not been merged at the time of writing. The Copilot AI's review comment has not been resolved. The HN thread is the place where this contradiction is being read carefully and the implications are being traced.

What goes into your git history

Co-authored-by: is a GitHub-recognized commit message trailer that surfaces in several places:

1. git log output — the trailer is part of the commit message itself. It is in your repository's history forever, on every commit produced under the new default.
2. GitHub's contribution graph and PR-author UI — Co-authored-by: lines are parsed and displayed; commits with the trailer are attributed to two parties.
3. License-attribution audits and IP-due-diligence reviews — when a startup is acquired or a project is open-sourced, someone runs a tool over the commit history to figure out who wrote what. A default-on Co-authored-by: Copilot trailer changes the answer of that question for every commit it appears on.
4. Contributor lists in AUTHORS files generated from commit history — depending on tooling, Copilot may show up as an author of your project.

It is worth reading carefully what the new default literally claims. The trailer says, in writing, that Copilot co-authored the commit. With the value set to "all", the claim is made on every commit, including commits where Copilot was demonstrably not invoked: a one-line typo fix, a gitignore update, a merge resolution, a commit produced by git commit --amend that only adjusts the previous commit's message. The claim is true sometimes. With this default, it is recorded always.

The HN reception

The thread's most-upvoted top-level comment frames the change as a standards problem rather than an attribution problem: AI-vendor defaults are increasingly hostile to the long-established conventions about whose name belongs on a piece of work. "Microsoft spent literal decades rehabilitating their reputation," the comment reads — and the implication is that the rehabilitation is being spent down on AI-feature-by-default decisions like this one. The same comment cites a Google example — keyboard-shortcut remapping on macOS to launch LLM features over a long-standing OS shortcut convention — and the slow accretion of small defaults that, taken together, redefine what an IDE is for.

A second thread of comments was structural — defaults are policy. The setting in git.addAICoAuthor has three plausible values — "off", "all", and (in some implementations) a value that detects whether the commit was actually AI-influenced. The PR didn't choose the detection path. It chose "all". That choice is a stance: Microsoft would rather record every commit as Copilot-co-authored than do the work of detecting which commits actually were.

The Copilot AI review's catch is, on its own merits, the most peculiar artifact in the PR. An AI flags a misalignment in the rollout of an AI feature, and the misalignment is still unresolved as the change moves toward merge.

What the opt-out actually does

The user-facing path to disabling the trailer is to set git.addAICoAuthor to "off" in your VS Code user settings. In the typical interactive flow, this works: the schema default is overridden by your user setting, the trailer doesn't get added, your commits stay clean.

The cases where it doesn't work are exactly the ones the Copilot AI review flagged. If your VS Code instance is loading in a host where contributed configuration defaults aren't fully populated — some test runners, some embedded hosts, the various dev-container and Codespaces flows that have their own configuration loading rules — the runtime fallback is what gets consulted. Right now the runtime fallback says "off", which produces the desired no-trailer behavior. After the PR merges and the runtime fallback gets aligned to match the schema default — which the Copilot AI review's "Update the runtime fallback to match the schema default" suggested change explicitly recommends — the "off" you set in your user settings will still win in normal VS Code sessions. But there will be specific load paths — particularly automation contexts — where the trailer is added to commits and your settings.json never had a chance to override.

The HN thread's running joke about "regardless of usage" is the operational summary of this: a feature whose opt-out is partial in ways that aren't documented, in flows that are hard to predict, in an IDE whose primary surface is committing code to other people's repositories.

Defaults are policy

The "off" → "all" change is one line in one file. It is also, on reflection, an unusually consequential one-line change. A substantial fraction of the world's commits flow through VS Code. A default-on AI-attribution trailer on those commits, ratified on every push, is a quiet but durable claim about authorship — a claim that Microsoft is making at scale, on behalf of its AI product, in your name and in your repository, written into the most-permanent log a project keeps.

It is worth saying that there is a coherent argument for this default. AI tooling is widely used. Recording its involvement is honest. A default that records the involvement removes the (real) friction of opting in commit-by-commit, and the (also real) under-attribution that comes from busy developers forgetting. That argument is not absurd. It is the argument the PR is implicitly making.

The argument the PR is not making — and would have to make to land cleanly — is why "all" is the right default rather than a detection-based setting that records co-authorship only when Copilot was actually invoked. The detection version is harder to implement; it is also the version that respects what Co-authored-by: actually means. "All" is the version that requires no engineering work and produces the most-frequent attribution claim. That this is the version that shipped is, on its own, a useful piece of information about how AI defaults are being made at the vendor in 2026.

What to do today

Three steps are worth taking this week if your commit history is part of your project's evidentiary record.

# 1. Disable the default in your user settings.json
{
  "git.addAICoAuthor": "off"
}

# 2. Audit recent commits in any repo you've worked in since 2026-04-15
git log --all --since='2026-04-15' \
  --grep='Co-authored-by: Copilot' \
  --pretty=format:'%h %an %ad %s' --date=short

# 3. If trailers slipped through, strip them on a topic branch
#    (rewrites local history; coordinate before pushing)
git filter-branch --msg-filter \
  'sed "/^Co-authored-by: Copilot/d"' HEAD~50..HEAD

And if you maintain an open-source project, document a contribution-trailer policy in CONTRIBUTING.md — a one-line rule against AI-attribution trailers regardless of IDE default turns a vendor-side default into a project-side norm. The vendor's default will keep changing. The project-side norm doesn't have to.

The PR that introduced this was one line. The cleanup, repo by repo, is going to take longer.