Thanks for the clear repro. Confirmed bug — aube config set was running a "stale alias" cleanup pass on ~/.npmrc so the new value in config.toml wouldn't be shadowed by the lower-precedence .npmrc. That workaround silently clobbered settings (like script-shell) that npm/pnpm/yarn also read.

Fixed in #608 with two coupled changes:

1. Flipped the default file precedence: aubeConfig > npmrc > workspaceYaml (was npmrc > aubeConfig > workspaceYaml). Aube's own config is now authoritative, matching what you proposed: "Reading the value can still read both, with preference for config.toml".
2. Dropped the .npmrc cleanup from both config set and config delete for aube-known keys. Your ~/.npmrc is preserved.

Per-setting precedence overrides in settings.toml (e.g. minimumReleaseAge) still apply — only the default file order changed.

This comment was generated by Claude.

Follow-up: jdx pointed out that project .npmrc should absolutely win (scope locality), and asked for parallel project-scope support for .config/aube/config.toml. Both are now in #608.

The new default precedence:

cli > env
    > project_aube_config (<cwd>/.config/aube/config.toml)
    > project_npmrc       (<cwd>/.npmrc + npmrcAuthFile)
    > user_aube_config    (~/.config/aube/config.toml)
    > user_npmrc          (~/.npmrc + pnpm auth.ini)
    > workspace_yaml

Two principles: scope locality (project beats user) and aube authority within a scope (aube's config file beats .npmrc). So aube config set scriptShell foo writes to ~/.config/aube/config.toml, leaves ~/.npmrc alone, and any project .npmrc setting still wins for that project.

Project-scope .config/aube/config.toml is now an alternative to committing aube-specific settings into a project .npmrc shared with npm/pnpm/yarn. aube config set --location project <aube-known-key> <value> writes there.

This comment was generated by Claude.