Attribution opt-out does not survive new attribution features (attribution.sessionUrl re-enables Claude-Session trailer despite commit/pr set to "")

Summary

An explicit, complete opt-out from commit/PR attribution does not survive the addition of new attribution features. Each new attribution channel ships with its own key defaulting to enabled, with no relationship to the opt-out the user already set. The user is silently re-enrolled on upgrade.

This is a correctness problem on its own terms. It is also a legal exposure problem in Canada, which is set out separately below.

Reproduction

Claude Code 2.1.220, macOS.

~/.claude/settings.json, set well before this version:

"attribution": {
  "commit": "",
  "pr": ""
}

Per the documented schema, empty string hides that attribution. At the time it was set, those two keys were the complete attribution surface.

Observed: Claude Code still injects an instruction into the model's system prompt directing it to append a Claude-Session: https://claude.ai/code/session_... trailer to commit messages, and the corresponding link to PR bodies.

Cause: a separate key, attribution.sessionUrl, which defaults to true:

Whether to append the claude.ai session link to commits and PRs created from web or Remote Control sessions (default: true). Set to false to omit the Claude-Session trailer and PR-body link.

Workaround:

"attribution": {
  "commit": "",
  "pr": "",
  "sessionUrl": false
}

The actual defect

The opt-out is per-key, not per-category. Setting every attribution key that exists today does not opt out of attribution — it opts out of those keys. When a new attribution channel is added, it arrives enabled, and a user who has already expressed an unambiguous preference has to discover the new key and re-opt-out.

There is no notification, no changelog entry surfaced in-product, and no way to express "no attribution, ever, including mechanisms that don't exist yet." Users who care about this are the users least likely to be re-reading the settings schema after every release, and the failure is silent — the trailer simply reappears in their commits.

Note also that attribution.commit: "" and attribution.pr: "" were already set to empty. The most natural reading of that configuration is "emit no attribution in commits or PRs." sessionUrl overrides that reading through a different code path.

Requested fix

One unified switch, never overridden by later additions. Concretely, any of:

1. A category-level attribution.enabled: false that suppresses all current and future attribution channels, taking precedence over every individual key; or
2. New attribution keys inherit an existing explicit opt-out rather than their own default — if a user has set commit: "" and pr: "", a newly added attribution channel defaults to off for them; or
3. At minimum: attribution defaults to off, and is opt-in.

Option 1 or 2 is preferred. Option 3 alone still leaves the per-key fragmentation in place.

Canadian legal exposure

This section is why the above is not a cosmetic issue for Canadian users.

Canada is not a US-law jurisdiction for this, and the difference is not marginal.

Under the Copyright Act, RSC 1985, c C-42, s. 14.1(1), the author of a work holds the right to the integrity of the work and, where reasonable in the circumstances, the right to be associated with the work as its author. Under s. 14.1(2), those rights may not be assigned. Sections 28.1–28.2 address infringement; s. 34(2) provides remedies.

Economic copyright can be assigned in Canada, in writing (s. 13(4)). Moral rights cannot be assigned at all. There is no Canadian equivalent to US work-for-hire doctrine that reaches them, and US moral rights are narrow by comparison (VARA, certain visual art only). Conduct that is routine and unremarkable in the US is not thereby lawful here.

The code behaviour described above attaches a marker associating a third party with the author's work, on the author's own repository, by default, and does so through a channel the author's existing opt-out did not cover. That the marker is a session URL rather than a Co-Authored-By: line does not change what it does: it associates the work with a party other than its author.

The relevant point for this issue is that the software makes this the default and makes opting out unreliable across versions. Whatever contractual position Anthropic believes it occupies, the engineering behaviour is that a user who has expressly configured "no attribution" receives attribution anyway after an upgrade, silently, in a git artifact that is then published, mirrored, and archived beyond their control. Commits are not easily retracted. The harm is not undone by fixing the flag later.

Canadian users of this software should not have to audit a settings schema after every release to preserve a right they never waived. I am documenting instances of this.

I would suggest Anthropic obtain Canadian counsel on the moral rights question specifically, rather than assuming the US analysis transfers. It does not.

Ask

One unified attribution switch that later features cannot override. This resolves the engineering defect and the legal exposure in the same change.

---

The legal analysis above reflects my position as the affected author and the basis on which I am documenting these instances. It is not legal advice to Anthropic; Anthropic should obtain its own Canadian counsel.