Skip to content

Installer silently overwrites a deliberately-empty attribution in ~/.claude/settings.json #1361

Description

@Dmitriusan

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

  1. 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".
  2. 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.
  3. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions