Loading today’s stories
Build1 distinct publisher2 min readUpdated
A permissions field became mandatory the same day the flags to set it shipped, so the only npm that can name the missing argument is the one that would never have sent the bad request.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The client-side check and the server-side requirement arrived on the same date [1][3], which makes the diagnosis circular: the only CLI that will name the missing flag is the one that would never have sent the rejected payload in the first place.
Recency is no protection here. npm 11.14.1 shipped on 8 May 2026 and 11.15.0 on 20 May [2][3], twelve days apart [14]. A machine that upgraded npm in the first half of May behaves identically to the one in the writeup, which was running February's 11.11.0 [5].
The remedy is a version bump, and the bump has a gate of its own. npm 12 declares support for Node ^22.22.2, ^24.15.0 or 26 and above, and on Node v24.14.1 the install is refused outright with notsup [7]. The useful detail is that you do not need to move the project's npm at all: the trust command only talks to the registry, so `npx -y [email protected] trust github` with `--allow-publish` gets the configuration written from a throwaway process [8].
Behind the flag sits a structural limit that no flag fixes. Trusted publishing is attached from an existing package's settings page, so OIDC cannot perform a package's first publish; version one goes out by hand, and every release after that runs without a token [9]. Anyone arriving from PyPI will expect otherwise, since PyPI lets you register a pending publisher for a name that does not exist yet [10]. The author's caveat is the honest kind: npm's own trusted publishing documentation does not state the limitation in either direction, the constraint is recorded in open npm/cli issue 8544, and publish-then-attach is third-party convention rather than a documented procedure [11].
The last trap belongs to unattended jobs. Both `npm publish` and `npm trust` require a second factor, and when npm cannot open a browser it prints an approval URL, which a non-interactive shell redacts to `https://www.npmjs.com/auth/cli/***` in the console and in the debug log alike, leaving nowhere to recover it; allocating a pseudo-terminal brings the real URL through [12].
So the registry tightened what it accepts and the client's error reporting did not move with it. The failure looks like a broken workflow file and is actually a question of which fortnight your npm binary came from.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
On 20 May 2026 npm began requiring every trusted publisher configuration to name at least one allowed action, and shipped the CLI flags for it the same day.
npm 11.14.1 (released 8 May 2026) and older accept the trust command, send a payload with no permissions field, and the registry answers 400 Bad Request with no body.
npm 11.15.0 (released 20 May 2026) and newer refuse the command client side with: At least one permission flag is required (--allow-publish, --allow-stage-publish).
The verbose log records only the http fetch POST 400 line and a stack trace; there is no error body to read, so raising the log level does not help.
The machine the author hit this on ran npm 11.11.0, shipped in February 2026, three months before the rule changed.
The fix is to run a newer npm and pass a permission flag, for example npm trust github --file publish.yml --repository your-org/your-repo --environment npm --allow-publish.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-hand reproduction, single publisher, no primary artifacts
The technical core is unusually concrete for a single-source story: the author pinned the failing/reporting version boundary by running the same dry run against each release, quotes verbatim CLI error strings for the 400, the client-side permission error, and the npm 12 notsup refusal, and documents the empty debug log. What is missing is primary corroboration - no npm changelog, registry release note, documentation page, or GitHub issue is supplied - so the dated contract change and the issue status rest on one practitioner's testimony.
Registry change already enforced; user impact unquantified
The change is not a proposal: the permissions requirement is live registry behaviour, the CLI that satisfies it has shipped, and the author has a working tokenless release pipeline as a result. Every pre-20-May-2026 CLI is implicitly in the affected population, but the cluster gives no counts of affected publishers, packages, or CI pipelines, so breadth is asserted by mechanism rather than measured.
Slightly understated relative to blast radius
The framing is deliberately modest - a troubleshooting note about one command and one flag - and the claims stay within what the author actually reproduced, with an explicit warning not to present the first-publish limitation as documented. If anything the piece undersells its own finding: a registry contract that changed the same day the flags to satisfy it shipped means every older CLI fails with no diagnosable output, which is a broader release-pipeline hazard than the personal-debugging register suggests.
Mild self-interest: developer-marketing post around own package release
The account arises from the author publishing their own JavaScript client and is written in the SEO-friendly how-to form typical of developer-platform posts, which rewards traffic on the error string. There is no vendor sponsorship, commercial product pitch, pricing claim, or adversarial stance toward npm evident in the supplied material, and the recommendations point to first-party tooling rather than anything the author sells, so distortion pressure reads low.
Mechanically coherent but single-sourced
Internal consistency is high - the dated registry change, the pinned version boundary, the empty error body, and the corrective flag all explain one another - and the reproduced command output is the kind of detail that is hard to fabricate. Confidence is held mid-range because a single publisher supplies everything, the 20 May 2026 date and the open npm/cli issue lack primary confirmation, and the surrounding traps (Node engine floor, TTY-less two-factor redaction) are reported from one environment only.
build
The npm audit that works because it never installs the package1 distinct publisher
build
Your CI Build Is Slow Because The Cache Is Empty, Not Because The Base Image Is Fat1 distinct publisher
build
A file-copy Allure adapter for Katalon, and the history IDs that make retries useful1 distinct publisher
security
The 2,500-org compromise was a Trivy problem. LiteLLM was the closing act.1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026