pnpm 12 is incompatible with the image's --ignore-scripts install

[dtump]

pnpm 12 cannot be installed the way the image installs npm tools, so the pin is
held at 11.23.0 (PR #52). This issue tracks getting back onto a supported pnpm.

What changed upstream

pnpm 12 moved its npm distribution from a JS bundle to a native binary:

	v11.23.0	v12.1.0
bin.pnpm	bin/pnpm.mjs (real JS entrypoint)	pnpm — a shebang-less placeholder text file
scripts.preinstall	—	node install.js
binary source	bundled in the tarball	@pnpm/exe.linux-{x64,arm64} optional dep

install.js hard-links (or copies) the native binary from the optional dep over
that placeholder. Dockerfile:243 installs with --ignore-scripts, so it never
runs, /usr/bin/pnpm stays the 282-byte placeholder, and sh tries to execute
its prose:

/usr/bin/pnpm: line 4: syntax error near unexpected token `)'
/usr/bin/pnpm: line 4: `pnpm's build under pnpm or Bun, or drop --ignore-scripts).'
  FAIL  pnpm  pinned=12.1.0  reported=<probe failed>

pnpm ships no fallback here, by design — from install.js:

A placeholder (not a Node launcher) is required because the Windows shim is
generated from the bin file and npm won't re-read package.json after
preinstall; the tradeoff is no fallback when build scripts are blocked
(--ignore-scripts, pnpm/Bun default).

So this is not a bug that will be patched away. Any pnpm 12+ bump breaks the
image until we choose a path.

Options

1. Run install.js ourselves after the install — the same carve-out
   claude-code's install.cjs already gets on the line below. It is
   platform-detect plus a hard-link/copy from an already-installed optional dep:
   no network, no exec. Cheapest fix, and it keeps --ignore-scripts on for
   every package including pnpm's transitive deps. Costs a second entry in that
   comment block and the same re-read-on-each-bump discipline (the script is
   upstream code that runs at build time, so a bump could change what it does).
2. Install pnpm from @pnpm/exe.linux-* directly and place the binary
   ourselves, skipping the wrapper package entirely. No upstream script runs at
   all. Needs per-arch handling in the Dockerfile (amd64 + arm64) and a pins
   change, since the version would come from a different package.
3. Enable Corepack instead. install.js notes Corepack runs no lifecycle
   scripts and enters through bin/pnpm.mjs, so it sidesteps the placeholder.
   But Corepack resolves and downloads pnpm at first use, which moves a pinned
   build-time dependency to an unpinned runtime fetch — probably not what this
   image wants.
4. Stay on 11.x indefinitely. Viable short-term (11.x still gets patches),
   but it accrues drift and 11 will eventually go EOL.

Option 1 looks right; option 2 is the stricter alternative if we would rather
not run upstream install scripts at all.

Also needed: stop the weekly refresh from re-proposing pnpm 12

update_pins.py picks the newest soaked stable version per tool. Nothing stops
it re-proposing 12.x next Monday, so this PR's failure repeats weekly until this
issue is closed. --block-major-bumps exists but is a global flag, applied to
every tool on the run — too blunt.

Preferred: a per-tool major ceiling on Tool (pnpm stays within its current
major) rather than a blanket ignore, so pnpm still picks up 11.x patch and
security releases automatically. Removing the ceiling becomes part of closing
this issue. Wants an OpenSpec change of its own.

[stefanwb]

The premise here is obsolete — upstream fixed this in pnpm 12.3.0

This issue states that pnpm ships no fallback when build scripts are blocked,
and that "this is not a bug that will be patched away." That was accurate for
12.1.0. It is no longer true: the fallback landed in pnpm 12.3.0 and was
hardened again in 12.3.3.

Verified against current latest (12.3.4) in a throwaway npm prefix:

npm install -g --ignore-scripts pnpm@12.3.4
pnpm --version   →   12.3.4   (exit 0, no stderr under a non-TTY)

Two things changed upstream:

1. The bin.pnpm placeholder is no longer prose. It is a valid shebang-less
   sh script that resolves symlink hops and exec node ./bin/pnpm.mjs.
2. The platform package (@pnpm/exe.linux-*) is installed under
   --ignore-scripts — it's an optional dependency, filtered by os/cpu/
   libc, not a script product. bin/pnpm.mjs finds it locally via
   resolveInstalledBinary() and spawns it. No network fetch.

From pnpm's CHANGELOG under ## 12.3.0 (pnpm/pnpm#14346):

The pnpm executable of the npm package now works when the package was
installed without running its install scripts, as under --ignore-scripts
[…] In that case it runs through Node.js and, in a terminal, says how to
switch to the native binary.

What that means for the options above

• Option 3 (Corepack) and option 4 (stay on 11.x indefinitely) are moot.
• Option 1 (run install.js ourselves) is the way forward — see below.
• Option 2 (place the @pnpm/exe.linux-* binary ourselves) is rejected as
  the more complex choice, not the stricter one. native-binary.mjs resolves
  four Linux targets (linux-x64, linux-arm64, and a -musl variant of
  each) and selects between them via detectLinuxLibc(), which reads
  process.report.getReport().header.glibcVersionRuntime. A Dockerfile
  cp/ln would have to duplicate that logic and would drift from it.
• The per-tool major ceiling in update_pins.py is not needed. The probe
  now passes on its own, so there is nothing to suppress. I'd argue against
  building it at all: a ceiling is stale-by-construction and its failure mode is
  silent stagnation on an old major, i.e. we'd quietly stop ingesting upstream
  fixes with nothing going red.

What actually remains to be done

A plain bump to 12.3.4 works, but lands in a degraded mode: a Node startup
hop on every invocation, plus a nag on stderr whenever stderr is a TTY — visible
to interactive users of the image every time they run pnpm.

Worse, CI cannot currently detect that state. The version probe runs
docker run --rm claude-docker:ci pnpm --version with no TTY, and pnpm's nag is
gated on [ -t 2 ]. So degraded mode prints a clean 12.3.4 to stdout and
passes. The probe can't distinguish healthy from degraded by construction.

So the residual task is three coupled changes:

1. Bump pins/pnpm.env to 12.3.4.
2. Run pnpm's install.js after the --ignore-scripts install, alongside the
   existing claude-code install.cjs carve-out. On Linux this is pure
   filesystem — its only imports are console/child_process/fs/path/
   process, and the single spawnSync is inside relinkNpmWindowsShims(),
   which returns immediately unless process.platform === 'win32'. It
   hard-links the platform binary over the placeholder (verified: same inode,
   36 MB, link count 2) and rewrites the bin map. Cost: the Dockerfile's
   re-read-on-each-bump discipline now covers a second upstream script.
3. Assert at build time that the placeholder was actually replaced — the
   highest-value item of the three, since it's the only one that closes the
   blind spot above. This cannot live in the update_pins.py --list-tools
   registry, which carries version probes only; it needs to be an artifact check
   in the Dockerfile that fails the build.

Note the failure mode without (2) is degraded, not broken — so the carve-out
is materially safer than the claude-code one, where skipping install.cjs
leaves a stub that errors at exec.

Timing — a ~2.5 day window, and the risk is silence rather than a red build

run_audit() checks the pinned version against the soak window and fails
closed, so an under-soaked pin fails CI regardless of how it was written
(--pin bypasses the resolver, not the audit gate). pnpm 12.x publish dates:

version	published (UTC)
12.1.0	2026-08-29	what PR #52 tried; broken
12.2.1	2026-09-01 00:56	pre-fix, still broken
12.3.0	2026-09-02 16:27	the fix
12.3.4	2026-09-04 14:20	current latest

12.3.4 clears the 7-day soak on 2026-09-11 14:20 UTC, so nothing can be
pinned before then.

The next scheduled refresh is Mon 2026-09-14 05:23 UTC. Its soak cutoff
(2026-09-07 05:23) makes 12.3.4 eligible, so if nothing lands first the bot will
bump pnpm to 12.3.4 by itself and CI will go green in degraded mode — for
exactly the reason above. The Dockerfile side cannot be pre-landed to get ahead
of it either: pnpm 11.23.0 ships no install.js, so there is nothing for the
build to call until the pin is on 12.x.

All three changes therefore want to land together in the window Fri
2026-09-11 14:20 → Mon 2026-09-14 05:23. If that slips the result is not a
failing build, it's a silent degradation that needs a follow-up to notice and
undo — which is the main argument for treating item 3 as the priority.

Caveat on the evidence

All binary-level checks above were run on arm64. The x64 platform package
was not tested; the mechanism is identical but that's an inference, not a
measurement.

Proposed retitle

pnpm: bump to 12.3.4, link the native binary, assert it at build time

Happy to leave the original body intact with the diagnosis as historical
context — the verbatim syntax error near unexpected token ')' string is worth
keeping for anyone who hits this on a pre-12.3.0 pin.

(Broader npm/pnpm supply-chain posture — release-age cooldowns and where the
package-manager choice is recorded — is a separate discussion and deliberately
out of scope here.)