Summary
Wiring Claude Code replaces the attribution block in ~/.claude/settings.json without asking, including when the user has deliberately disabled attribution by setting it to empty strings. Every commit and PR the agent subsequently creates is credited to Weave Router.
Reproduction
Starting state — attribution explicitly disabled:
"attribution": {"commit": "", "pr": "", "sessionUrl": false}
Run:
./install/install.sh --claude --local --scope user --non-interactive
Resulting state:
"attribution": {
"commit": "Co-Authored-By: Weave Router <router@workweave.ai>",
"pr": "🤖 Generated with [Weave Router](https://router.workweave.ai)"
}
The values come from install/install.sh:5759-5768. sessionUrl: false is dropped in the process, and nothing in the installer's output mentions that attribution was changed.
Environment: weave-os/router @ d467833, self-hosted (docker compose), Claude Code, user scope.
How it surfaces
Claude Code reads that field and generates a per-session <system-reminder> instructing the model to apply those trailers to every commit and PR it creates. In the session transcript it arrives as a harness record:
{"type": "remote_session_change", "url": null,
"commit": "Co-Authored-By: Weave Router <router@workweave.ai>",
"pr": "🤖 Generated with [Weave Router](https://router.workweave.ai)",
"sendUserFileHint": false, "managedCommit": false, "managedPr": false}
So the installer's write to settings.json does not just sit in a config file — it propagates into the agent's standing instructions for the session, phrased as an authoritative directive that overrides prior attribution guidance.
For a user who had attribution disabled on purpose and does not know the installer touches that field, the visible symptom is an unexplained instruction to credit a third party in their git history. That reads as something hostile before it reads as a config default, and it cost me a full audit of the translate layer to rule out. Worth noting that install/uninstall.sh:987-989 already does the careful thing on the way out: it only clears the field if the value still matches exactly what the installer wrote.
Why this warrants a prompt rather than a silent default
- It writes into the user's git history under a third party's name. Commit trailers are permanent and usually pushed to shared repositories, which puts "credit Weave Router in every commit" in a different category from "point this client at localhost:8080".
- An empty string is an explicit choice, not an unset default. Users who disabled attribution did so deliberately; that value is a signal the installer could honor.
- It is invisible. The change is not announced, so the first time most users learn about it is when they read a commit they already pushed — or when they see the system reminder and have no idea where it came from.
Suggested fix
In rough order of preference:
- Treat an existing
attribution block whose commit and pr are empty strings as an opt-out and leave it untouched.
- Otherwise prompt before overwriting a non-default
attribution; under --non-interactive, leaving it untouched seems the safer default.
- At minimum, print a line stating that attribution was changed and how to revert it.
Preserving sessionUrl when rewriting the block would be worth fixing either way.
Summary
Wiring Claude Code replaces the
attributionblock in~/.claude/settings.jsonwithout asking, including when the user has deliberately disabled attribution by setting it to empty strings. Every commit and PR the agent subsequently creates is credited to Weave Router.Reproduction
Starting state — attribution explicitly disabled:
Run:
Resulting state:
The values come from
install/install.sh:5759-5768.sessionUrl: falseis dropped in the process, and nothing in the installer's output mentions that attribution was changed.Environment:
weave-os/router@d467833, self-hosted (docker compose), Claude Code, user scope.How it surfaces
Claude Code reads that field and generates a per-session
<system-reminder>instructing the model to apply those trailers to every commit and PR it creates. In the session transcript it arrives as a harness record:{"type": "remote_session_change", "url": null, "commit": "Co-Authored-By: Weave Router <router@workweave.ai>", "pr": "🤖 Generated with [Weave Router](https://router.workweave.ai)", "sendUserFileHint": false, "managedCommit": false, "managedPr": false}So the installer's write to
settings.jsondoes not just sit in a config file — it propagates into the agent's standing instructions for the session, phrased as an authoritative directive that overrides prior attribution guidance.For a user who had attribution disabled on purpose and does not know the installer touches that field, the visible symptom is an unexplained instruction to credit a third party in their git history. That reads as something hostile before it reads as a config default, and it cost me a full audit of the translate layer to rule out. Worth noting that
install/uninstall.sh:987-989already does the careful thing on the way out: it only clears the field if the value still matches exactly what the installer wrote.Why this warrants a prompt rather than a silent default
Suggested fix
In rough order of preference:
attributionblock whosecommitandprare empty strings as an opt-out and leave it untouched.attribution; under--non-interactive, leaving it untouched seems the safer default.Preserving
sessionUrlwhen rewriting the block would be worth fixing either way.