aube config get allowBuilds reports a ~/.npmrc value that aube install ignores

[mwolson]

aube config get allowBuilds reports a value from the user-level ~/.npmrc that aube install then ignores.

$ cat ~/.npmrc
allowBuilds={"esbuild":true}

$ aube config get allowBuilds
{"esbuild":true}

$ aube install
WARN aube::commands::install::unreviewed_builds: ignored build scripts for 1 package(s): esbuild@0.25.12

$ aube ignored-builds
The following builds were ignored during install:
  esbuild@0.25.12

The same allowlist in package.json#aube.allowBuilds is honored, so this is a divergence between config sources rather than an unsupported setting.

Either the install path should read it, or config get should not report a value from a location the install ignores. As it stands the documented way to check the setting actively confirms a configuration that has no effect, which is a slow thing to debug: it looks like the allowlist is applied and the build is failing for some other reason.

Repro

https://github.com/mwolson/tmp-aube-issues/tree/main/pnpm-user-npmrc-allowbuilds-read-only

Runs entirely inside a throwaway HOME, so the real ~/.npmrc is untouched. Exits 1 on the bug, 2 if the environment or the read path has changed enough that the repro is stale.

AUBE_BIN=aube ./repro.sh

It also asserts the package.json#aube.allowBuilds control still works, so a future change that fixed this by dropping the setting entirely would be reported as a stale repro rather than a pass.

Relationship to #617

This is the read half of the problem @iki raised in #617: aube config set allowBuilds.<pkg> true used to write to ~/.npmrc, where it had no effect on aube. That write path now errors with ERR_AUBE_CONFIG_NESTED_AUBE_KEY, which is a good guard. The read path was not changed alongside it, so a hand-written ~/.npmrc entry still reads back as if it were live.

Versions

• aube 1.32.0 linux-x64 (2026-07-22) and 1.34.0 linux-x64 (2026-07-27), same behavior on both
• Linux x64, glibc

[jdx]

Confirmed and reproduced on current main.

The install behavior is intentional and fail-safe: the build policy only trusts project-scoped allowBuilds from workspace YAML and package.json#pnpm.allowBuilds / package.json#aube.allowBuilds. The bug was in config inspection: it merged raw .npmrc entries without checking whether that setting actually consumes .npmrc, while the settings metadata also incorrectly advertised .npmrc for allowBuilds.

PR #1159 fixes the read side by:

• removing .npmrc as an advertised allowBuilds source
• filtering known .npmrc settings from config get, config list, and the config TUI unless metadata declares that source
• preserving unknown free-form entries and supported camel/kebab aliases
• adding regression coverage for get, list, and explain

Validation: 69 config Bats tests pass, focused Rust coverage passes, and all-target clippy is clean.

AI-assisted — Tool: Codex; model: unavailable; version: unavailable.

[mwolson]

Confirmed fixed on aube 1.36.0 (fix shipped in 1.35.0 via #1159).

Retested the minimal repro at https://github.com/mwolson/tmp-aube-issues/tree/main/pnpm-user-npmrc-allowbuilds-read-only: with allowBuilds={"esbuild":true} only in a throwaway ~/.npmrc, aube config get allowBuilds now returns undefined instead of reporting a value install would ignore. package.json#aube.allowBuilds still allows the build. The same repro still fails on 1.34.0.

Marking the fix reply as the answer; leaving the discussion open for searchability.