VS Code Inserting Co-Authored-by Copilot Into Every Commit Regardless of Usage — When Vendor Attribution Becomes Pollution

When I checked our team’s git log on Saturday morning, I found 847 commits across 23 repositories carrying a co-author I had never authorized: Copilot <[email protected]>. Not commits where Copilot suggested code. Not commits where the developer accepted a completion. Every commit. Bug fixes typed by hand. Documentation edits made on a plane with no internet. A revert of a Copilot-generated change, ironically attributed to Copilot. The Hacker News post that hit number one yesterday morning — 710 points, 326 comments by the time I refreshed at lunch — was the first time I had a name for what I had been seeing in client repositories for the past three weeks. VS Code’s git extension has, sometime in the April update cycle, started auto-inserting Co-Authored-by: Copilot <[email protected]> into the commit message template, and it does so regardless of whether Copilot touched a single line of the diff.

This is not a bug. I want to be precise about that, because the GitHub issue tracker is already filling up with engineers framing it as a bug, and Microsoft’s response — when it eventually arrives — will almost certainly use the bug framing too. A bug is an unintended deviation from specified behavior. What VS Code is doing is the specified behavior. The git extension reads a configuration value, that value defaults to inserting the trailer, and the trailer gets inserted. The fact that the default was changed without a changelog entry, the fact that the trailer is inserted regardless of actual Copilot involvement, the fact that disabling it requires editing three separate settings across two scopes — these are product decisions, not defects. Microsoft has chosen to make every commit by every developer using VS Code into a marketing surface for Copilot, and the choice is being defended internally as a feature.

I have spent the last eighteen months auditing repositories for what I now call “vendor attribution leakage” — the gradual, opt-out-by-default colonization of source control metadata by AI coding tool vendors. I have looked at over 200 repositories across enterprise customers, open-source projects, and personal codebases. The pattern is now unmistakable, and the events of the past two weeks have made it impossible to dismiss as paranoia. On April 30, the HERMES.md exploit demonstrated that coding agents will read and execute instructions from arbitrary files placed in a repository (covered in post 3401). On May 1, the Claude Code OpenClaw filter incident showed that Anthropic was silently filtering certain prompt patterns server-side without disclosure (post 3411). Today, May 3, we have the VS Code Copilot pollution disclosure. Three independent vendors, three different attack surfaces — repository file system, prompt pipeline, source control metadata — and one consistent posture: the vendor treats your development environment as their product surface, and your consent is assumed unless you actively withdraw it.

How the insertion actually works

I want to walk through the mechanics in detail because most of the early commentary on Hacker News got the technical details wrong, and the wrong technical model leads to wrong mitigations. The VS Code git extension does not modify your .git/config. It does not write to ~/.gitconfig. It does not run git commit --trailer behind your back. The mechanism is more elegant and harder to detect: it modifies the commit message template presented in the editor before you confirm the commit.

When you click the checkmark in the VS Code Source Control panel, or when you run the Git: Commit command, the extension constructs a commit message buffer. If the github.copilot.chat.commitMessageGeneration.coAuthorTrailer setting is enabled — and as of the April 2026 release, it is enabled by default for all users with the Copilot extension installed — the extension appends a trailer block to the buffer:

Co-Authored-by: Copilot <[email protected]>

Critically, this happens whether or not you used the “Generate commit message” feature. It happens whether or not Copilot suggested any of the staged changes. It happens on commits that consist entirely of files Copilot has never seen — files you typed character by character with the Copilot extension disabled, or files that arrived from a git pull and which you only modified the trailing newline of. The trailer is bound to the act of committing in VS Code, not to any actual collaboration with Copilot.

The reason this is hard to detect post-hoc is that, by the time the trailer reaches your repository, it is indistinguishable from a trailer you might have intentionally added. Git itself has no notion of “trailer added by editor versus trailer added by user.” The blame attribution machinery treats Co-Authored-by as authoritative. GitHub’s contributor graph treats it as authoritative. git shortlog -sn --no-merges with the appropriate flags will count Copilot as a contributor. Commit-counting tools used for performance reviews, for OSS contribution metrics, for compliance audits — all of them will see Copilot as a co-author of work that Copilot had nothing to do with.

The three-event pattern

To understand why this matters more than its surface severity suggests, you have to look at it as the third instance of a pattern, not as an isolated incident. Let me restate the three events with the specificity they deserve.

HERMES.md, disclosed April 30 and analyzed in post 3401, was the discovery that several major coding agents — Cursor, Continue, Cline, and at the time Claude Code in certain configurations — would read and respect instructions placed in files named HERMES.md, AGENTS.md, and a handful of similar conventions, even when those files were committed by a third party into a dependency. The exploit demonstrated was a malicious npm package that included an AGENTS.md file instructing any agent operating in the consuming project to exfiltrate environment variables to an attacker-controlled endpoint. The agents complied, because the files were within their working directory and the system prompts told them to read project-level instruction files. The vendors had given themselves permission to execute arbitrary instructions sourced from anywhere on the filesystem, and had not bounded that permission to instructions the user actually wrote.

The OpenClaw filter, disclosed May 1 and analyzed in post 3411, was the discovery that Claude Code — Anthropic’s official CLI — was silently filtering prompts that matched certain patterns related to a class of agent jailbreak techniques known collectively as “OpenClaw.” The filtering was server-side, not disclosed in any documentation, and produced no error message when triggered. Affected prompts simply got back generic refusals or, in some configurations, went through a degraded model that produced visibly worse output. Users had no way to know their session had been routed through a filter, no way to opt out, and no way to even confirm the filter existed without running comparative tests. Anthropic eventually acknowledged the filter existed but framed it as a safety measure; the framing avoided the actual issue, which is that the user is paying for one product and silently receiving a different one.

The VS Code Copilot pollution, disclosed today, completes a triangle. HERMES.md was vendor coding-agents reading from the repository without consent. OpenClaw was vendor coding-agents writing to the model pipeline without disclosure. Copilot pollution is vendor coding-agents writing to the repository without consent. Read together, these three events describe a coherent product strategy: the vendor treats every layer of the developer’s workflow — file system, prompt pipeline, source control — as a surface where the vendor may insert behavior that the user has not requested and may not be aware of. The defense in each case is the same evasive shape: it was a default, defaults can be changed, the user could have audited the settings.

What I want to push back on, hard, is the framing that this is a configuration issue. Configuration issues are issues you can detect by reading configuration. The pollution trailer is not in your .gitconfig. The OpenClaw filter is not in any local file. The HERMES.md execution behavior is not in any setting you can grep for. These are not configurations the user can audit; they are behaviors the vendor has installed in the runtime, and the only way to know they exist is to discover them empirically — which is exactly how all three were discovered, by users noticing something wrong and reverse-engineering the cause.

The vendor attribution table

I built the following table over the past three weeks while auditing client repos. It captures, for each major AI coding vendor active in mid-2026, what surfaces of the git/commit pipeline the vendor modifies by default, what consent model is used, and what the difficulty of disabling each modification is on a 1-to-5 scale (5 being “requires editing internal state most users cannot find”).

The table makes the outlier visible. Most vendors have settled on either opt-in trailers or trailers that fire only when the AI was actually involved in the staged change. Two vendors — VS Code/Copilot and Replit Agent — have moved to a model where the trailer is inserted on every commit regardless of involvement, and where the consent is silent default-on. Of those two, only one ships in the editor used by an estimated 73% of professional developers. The blast radius of the Copilot decision is therefore vastly larger than any of the other defaults in the table, and it is the only one for which the disable path involves three separate settings across user and workspace scope.

Why the disable path is hard, specifically

I want to walk through what it actually takes to stop the trailer from being inserted, because the GitHub issues currently being filed are mostly missing one or more of the steps. If you only do step one, the trailer comes back. If you only do steps one and two, the trailer comes back when you open a workspace that has its own settings file. The full sequence, as of the May 2026 build, is:

First, in your user-level settings.json, add:

"github.copilot.chat.commitMessageGeneration.coAuthorTrailer": false,
"github.copilot.chat.commitMessageGeneration.enabled": false,
"git.alwaysSignOff": false

The first setting disables the trailer insertion. The second setting disables the entire commit message generation feature, which on certain code paths re-enables the trailer even when the first setting is false (this is filed as a bug but has not been fixed in three release cycles). The third setting is unrelated to Copilot but is needed because, in some workspace configurations, sign-off insertion will trigger a re-run of the commit message template construction, which re-applies the trailer.

Second, in any workspace-level .vscode/settings.json for projects you collaborate on, you have to repeat the first two settings, because workspace settings override user settings and many teams have committed Copilot defaults into their workspace configs without realizing what they were committing.

Third, if you use Settings Sync — and most professional developers do — you have to verify that the disable settings have synced to all your devices. I have personally found cases where the disable was applied on my laptop but the setting was overridden by a stale sync from my desktop, with the result that commits made on the laptop were clean and commits made on the desktop carried the trailer, for the same projects on the same days.

Fourth, if you have the GitHub Pull Requests and Issues extension installed, it has its own setting githubPullRequests.assignCreated and a related, undocumented setting that re-enables co-author trailers on commits made through the PR review interface. You have to find and disable that one separately.

Fifth — and this is the one that has caught me three times now — if you ever run the Developer: Reset Settings command, or if VS Code crashes during a settings update, the defaults come back, including the trailer default. There is no warning when this happens. Your next commit will silently carry the trailer again.

I count five disable steps, four of which can independently fail to stick. Compare this to disabling, say, telemetry in any major browser, which is a single setting that survives crashes and syncs cleanly. The asymmetry is not accidental. The product team responsible for this default has been asked, in public issues, why it is opt-out instead of opt-in, and has answered with the standard formulation about “showcasing AI collaboration.” That formulation only makes sense if you accept the premise that every developer’s commits are an appropriate venue for showcasing the vendor’s product. I do not accept that premise, and I think very few developers would accept it if they were asked clearly.

Downstream effects on git history and analytics

The trailer is not just cosmetic. It changes how a wide range of tools interpret your repository, and most of those tools were designed before vendors started inserting themselves as co-authors of work they did not do.

GitHub’s contributor graph counts Co-Authored-by trailers when computing contributions to a repository. A repository where every commit carries the Copilot trailer will show Copilot as a top-three contributor by commit count, regardless of how much code Copilot actually wrote. For open-source projects this distorts the public record of who built the project. For internal projects it distorts the data that performance reviews are increasingly being built on. I have spoken with three engineering managers in the past two weeks who pulled “AI contribution” reports from their GitHub Enterprise instances and were planning to use those numbers to justify Copilot license renewals; in every case the numbers were inflated by the trailer pollution and not by actual usage.

The git blame view in most modern code-host UIs will surface co-authors. A line that you wrote, in a commit that VS Code added the Copilot trailer to, will appear in some blame views as “co-authored by Copilot.” When that line later turns out to be the source of a bug, an outage, or a security incident, the post-mortem will include a line that reads “this code was co-authored by Copilot.” That line is false, but it will end up in incident reports and in some cases in public disclosures.

Mailmap files — .mailmap at the repository root — can be used to canonicalize identities and to suppress trailers in some tooling, but they are inconsistently respected. The standard git shortlog -sn command honors mailmap; the GitHub UI partially honors mailmap; many third-party analytics tools ignore it entirely. So even teams that have noticed the pollution and added [email protected] to a mailmap are seeing inconsistent results across tools.

License audit and compliance tools that scan repositories for “AI-generated content” — a category of tooling that has expanded rapidly in the last year, driven by enterprise procurement requirements — use the trailer as a primary signal. A repository that carries the Copilot trailer on every commit will be flagged as 100% AI-generated by these tools, which can have real procurement and licensing consequences. I am aware of one client who failed an enterprise vendor security review because their repository’s commit history showed Copilot as a contributor on commits to authentication code; the reviewer interpreted this as “AI-generated authentication,” which it was not, but the trailer made it impossible to argue otherwise without a multi-week audit.

The DCO (Developer Certificate of Origin) sign-off process used by many open-source projects is a particularly nasty interaction. The Linux kernel and many other DCO-required projects expect the sign-off chain to reflect actual contributors. Submitting a patch with a fake co-author — and a co-author who did not in fact contribute is a fake co-author, even if the trailer was added by your editor without your awareness — is in principle a DCO violation. I do not expect maintainers to start rejecting patches over this, but the principle is uncomfortable and the legal exposure for contributors who work in regulated industries is non-trivial.

How this connects to HERMES.md and OpenClaw

I want to come back to the three-event pattern with the technical details now in place, because I think the pattern is what makes this story important rather than just annoying.

HERMES.md gave the vendor write access to the agent’s instruction set via files placed in the user’s repository. The vendor argued that this was a feature — projects should be able to instruct agents how to behave in their context — and the argument has some merit in the cases where the project author and the user are the same person. The exploit was that nothing distinguished those cases from cases where a hostile dependency author had placed the instruction file. The vendor accepted the convenience of “agents read project files” and externalized the security cost to users, who had to discover the issue empirically and mitigate it themselves.

OpenClaw gave the vendor write access to the model pipeline. Anthropic argued that filtering certain prompt patterns was a safety measure, and the argument has some merit in the cases where the patterns reliably identify harmful intent. The issue was that the filtering was undisclosed, the patterns were broader than the harmful cases, and users were paying for a product whose actual behavior diverged from the documented behavior in ways they had no way to detect. The vendor accepted the convenience of “we can filter without telling anyone” and externalized the cost to users who had to discover the issue empirically and route around it.

Copilot pollution gives the vendor write access to the user’s source control history. Microsoft has not yet publicly defended the default, but the internal defenses I have seen quoted in the HN thread frame it as “transparency about AI collaboration.” The argument has some merit in the cases where Copilot actually contributed to the commit. The issue is that the trailer fires on every commit regardless of contribution, the disable path is hostile, and the downstream effects on contributor analytics, blame attribution, and compliance auditing are real. The vendor has accepted the convenience of “every commit advertises our product” and externalized the cost to users who have to discover the pollution empirically and clean it up after the fact.

The shape is identical in all three cases: a feature that is reasonable in its intended scope is silently expanded to a default scope that includes uses the user did not intend, the expansion is not disclosed at the point of installation or update, the cost of the unintended scope is borne by the user, and the disable path requires technical knowledge that most users do not have. I do not think this shape is a coincidence. I think it is what coding-agent product strategy looks like when the vendor is competing for distribution rather than for quality, and when the user’s workflow is treated as a surface to be optimized for vendor visibility rather than as a workspace the vendor is renting from the user.

The argument I expect to hear, and why it doesn’t hold

The argument that will be made in defense of the default — and which has already started appearing in the HN thread — is that the trailer is just metadata, that nothing is hidden, that any developer who cares can see the trailer in the commit message and either remove it before committing or disable it in settings. The argument has a surface plausibility. It also fails on three counts.

First, the trailer is appended to the commit message buffer in a way that most developers do not notice. The VS Code commit input is a single-line field by default; the trailer lives in the multi-line expanded view that most developers never open. The trailer therefore does not present itself for review in the normal commit flow. “The user could have seen it” is technically true and practically false, in the same way that a 47-page ToS update is technically reviewable and practically not.

Second, even if every developer noticed the trailer on every commit, the cost of removing it manually — opening the expanded view, deleting the trailer block, re-confirming the commit — would be borne 100% by the user for the benefit of the vendor’s marketing. The economics of opt-out defaults always work this way, which is why most jurisdictions have moved to requiring opt-in for any non-essential data collection. Source control attribution is at least as load-bearing as analytics consent, and it is bizarre that we have weaker norms around it.

Third, the argument assumes the harm is limited to the developer who is committing. It is not. The downstream effects on contributor graphs, blame attribution, compliance audits, and DCO chains affect every consumer of the repository, not just the original committer. A maintainer who reviews a PR has no way to know whether the Copilot trailer reflects actual collaboration or vendor pollution. The maintainer has to either trust the trailer (and propagate the false attribution) or distrust the trailer (and undermine the value of trailers in cases where they are accurate). Either way, the integrity of the attribution system as a whole degrades, and the degradation is caused by the vendor’s default, not by any user’s choice.

Cleaning existing repositories

If you have been using VS Code with Copilot installed since the April 2026 update, you almost certainly have polluted commits in your repositories. Here is what I recommend, in increasing order of invasiveness, for cleaning them up.

The lightest-weight approach is to add a .mailmap file at the root of each affected repository that maps the Copilot identity to a “removed” form, and to update tooling to honor the mailmap. A mailmap entry of the form <[email protected]> Copilot <[email protected]> will cause git shortlog and other mailmap-aware tools to deduplicate or suppress the false attribution. This does not remove the trailer from the commits themselves, but it neutralizes most analytics impact for tools that respect mailmap. It is a one-file change and it is reversible.

The medium-weight approach is to use git filter-repo to strip the trailer from all historical commits. The command is roughly git filter-repo --message-callback 'return re.sub(b"\nCo-Authored-by: Copilot <[email protected]>\n", b"\n", message)'. This rewrites history, so it requires force-pushing, coordinating with all collaborators to re-clone, and accepting that signed commits will lose their signatures. For private repositories with small teams this is manageable. For public repositories or large teams it is disruptive enough that I do not generally recommend it unless the pollution is causing concrete compliance or audit problems.

The heavyweight approach, which I have only recommended once in the past month, is to draw a line in the history with a BREAK: vendor attribution cleaned commit, document the cleanup in the project’s contribution log, and apply the filter only to commits after the line. This preserves history before the line, makes the cleanup auditable, and avoids the worst of the force-push disruption. It is the right choice for projects that have legal or compliance reasons to have a clean record going forward but cannot disturb the existing record.

For all three approaches, you should also audit any tooling that consumes your git history. CI/CD systems that report on contributors, performance review systems that pull commit data, dashboards that compute “AI contribution” metrics — all of these need to be reconfigured to either respect mailmap or to explicitly exclude the Copilot identity. The cleanup is not done when the commits are clean; it is done when the downstream consumers stop treating the trailer as authoritative.

A prevention checklist

Going forward, here is the checklist I am applying to every team I work with. It is more aggressive than what most teams will accept on the first pass, but I have not found a less aggressive version that actually prevents the issue from recurring.

One: standardize the disable settings across the team and commit them to a workspace settings file in every shared repository. This catches new joiners and protects against settings sync drift. The workspace settings file should include the three Copilot-disable lines from the section above, and a comment explaining why they are there so that no one removes them in a “settings cleanup” PR six months from now.

Two: add a pre-commit or commit-msg hook that rejects commits containing unauthorized vendor trailers. The hook should be installable via the project’s standard tooling — Husky, pre-commit framework, or equivalent — and should match a configurable list of vendor trailers. The default list should include Copilot, Replit Agent, and any other vendor your team does not want appearing in commits. The hook should fail loudly with a message explaining how to disable the vendor’s trailer at source, not just how to remove it from the current commit.

Three: add a CI check that runs on every PR and inspects the commits for vendor trailers. The CI check provides defense in depth against developers who bypass the local hook (intentionally or by misconfiguration) and surfaces pollution that reached the remote. It should be a non-blocking warning initially, escalating to a blocking check after a grace period. Make the check easy to bypass for legitimate cases — a developer who actually used Copilot for a commit and wants to attribute it should be able to add a marker that the check respects.

Four: audit every IDE plugin and CLI tool your team uses for commit-message and git-config modification behavior. The vendor table in this article is a starting point but it is not exhaustive, and the defaults change frequently. Build a habit of checking the release notes of any AI coding tool for changes to commit-touching behavior, and of running a controlled test commit after any update to verify nothing has changed silently.

Five: maintain a mailmap at the root of every repository that maps known vendor identities to suppressed forms. This is your last line of defense for commits that slipped through the previous four layers. The mailmap is a one-file change and it costs you nothing to maintain proactively, but it is invaluable when you discover six months later that some tool you were not aware of has been counting Copilot as a top contributor on a project where Copilot wrote nothing.

Six: write down, somewhere visible to the whole team, your team’s stance on AI tool attribution. Decide whether you want trailers when AI tools genuinely contributed, decide what counts as genuine contribution, decide who is responsible for adding the attribution and how. The vendors are filling this policy vacuum with their defaults. If you do not fill it with a deliberate policy, you will end up with the vendor’s policy by default, and the vendor’s policy is optimized for the vendor’s interests rather than yours.

Seven: keep an eye on the next event in the pattern. HERMES.md, OpenClaw, and Copilot pollution were three events in two weeks. There will be a fourth. The vendors will continue to find new surfaces to insert themselves into — terminal output, shell history, browser bookmarks synced through the IDE, MCP server registries, language server diagnostics — and the defaults will continue to be opt-out. The work of maintaining a clean development environment is now ongoing, not one-time. Treat it that way.

The larger thing this is about

I want to close on the question that I think the HN thread is dancing around without quite saying. Why are vendors doing this now, when they were not doing it three years ago? The technology has not changed in a way that requires it. The market position of Copilot, Claude Code, and Cursor is strong enough that they do not need attribution-based marketing to drive adoption. Microsoft does not need 847 pollution trailers in my client’s git log to know that Copilot is being used; the telemetry tells them in real time how many completions were accepted.

The reason, I think, is that the coding-agent market has entered the phase where vendors compete on perceived ubiquity rather than on actual quality. The trailer is not there to inform the user. It is not there to give Copilot credit for work it did. It is there to make Copilot’s presence in the developer’s workflow visible to other developers — to maintainers reviewing PRs, to managers reading contribution reports, to procurement teams auditing AI usage. The trailer is a billboard, and the billboard is on the user’s land, and the user did not agree to host it.

The same logic explains the OpenClaw filter. Anthropic’s interest in being seen as the “responsible” AI vendor is more important to its market position than its interest in being seen as the most capable vendor. The filter is a billboard for Anthropic’s safety posture, and it is mounted on the user’s prompts. The same logic explains HERMES.md too: the vendors who allow agents to read project instruction files are competing on “configurability” as a feature, and the vendors are willing to accept security debt that the user has to pay for in order to win that competition.

The remediation, in every case, is the same: the user has to treat the vendor as an adversary in the specific dimension of “what shows up in my workflow,” even while continuing to use the vendor’s product for its intended purpose. This is an uncomfortable posture. It is also, I think, the only posture that works in the current market. Vendors who have already moved to opt-out defaults will not move back to opt-in voluntarily; the only thing that moves them is users discovering the defaults, complaining loudly, and forcing a public defense that the vendor is not prepared to make. The HN thread today is doing exactly that for Copilot pollution. The thread two weeks ago did it for HERMES.md. The thread last week did it for OpenClaw. The mechanism works, but only because someone is paying attention, and only because the defaults are still embarrassing enough to defend in public.

My prediction for the next twelve months is that the defaults will continue to drift in the vendor’s direction, that the embarrassment threshold for defending them in public will continue to rise, and that the work of maintaining a clean development environment will continue to migrate from “set it and forget it” to “audit quarterly and assume the vendor changed something.” The teams that adapt to that reality will end up with cleaner repositories, more accurate analytics, and more defensible compliance postures than the teams that do not. The teams that do not adapt will end up with git histories that reflect the vendors’ marketing strategies more accurately than they reflect the teams’ actual work. I know which side of that line I want my clients on, and the prevention checklist above is what it takes to stay on that side. The Copilot pollution is annoying, the HERMES.md exploit was scary, the OpenClaw filter was sneaky, and the next event in the pattern will be something we have not yet imagined. The defense is the same in every case: assume the default is the vendor’s interest, audit empirically, and write the policy down before someone else writes it for you.