Summary
The contributor version policy is ambiguous at commit 4a53b01ec92cbe9ccae506bd9ea77935a73f3bf7: README, CONTRIBUTING and engines.pnpm advertise >=10.18.3, but packageManager and Linux/Windows CI pin 10.18.3. Running pnpm 11, which satisfies the advertised range, exposes an unreviewed dependency-build decision during installation.
This report does not claim the pinned pnpm 10.18.3 CI configuration fails.
Environment and reproduction
- Windows
- Node.js
v24.19.0
- Actual pnpm executable:
11.19.0
- Clean checkout at the commit above
node --version
pnpm --version
pnpm install --frozen-lockfile
The install exits 1 and reports:
[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: esbuild@0.27.7
Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.
It adds a pending decision to pnpm-workspace.yaml:
allowBuilds:
esbuild: set this to true or false
This placeholder is documented pnpm behavior, not accidental configuration corruption. A contributor following the broad minimum-version requirement nevertheless needs an extra policy decision that the quickstart does not explain.
Local remedy tested, with limits
For pnpm 11.19.0, adding this to the existing workspace configuration made the same frozen install succeed and run esbuild postinstall:
allowBuilds:
esbuild: true
pnpm check passed across the workspace, including a fresh recheck on September 14 UTC. The existing minimumReleaseAge: 10080 was unchanged. This approves esbuild scripts by package name, not just version 0.27.7, and does not authorize other packages.
This is not proposed as a universal fix for the current version range: allowBuilds was introduced in pnpm 10.26.0, after the repository/CI pin of 10.18.3. I have not tested the remedy under that older pinned version.
Suggested resolution
Please choose and document one consistent policy:
- Require the exact pnpm 10.18.3 version and align README, CONTRIBUTING, engines and the contributor setup instructions with that pin; or
- Explicitly support newer pnpm versions, review the appropriate allow/deny build policy, align the pin/range and add a clean Windows + pnpm 11 installation check.
Approving esbuild is a tested local option, not the only permissible security decision. The issue is the mismatch between the advertised contributor range and the pinned/tested workflow.
All reproduction work used local checkouts. No CALL-E API request or phone call was made. This report, the local reproduction and the proposed configuration change were prepared with substantial OpenAI Codex assistance under the account owner's direction.
Summary
The contributor version policy is ambiguous at commit
4a53b01ec92cbe9ccae506bd9ea77935a73f3bf7: README, CONTRIBUTING andengines.pnpmadvertise>=10.18.3, butpackageManagerand Linux/Windows CI pin10.18.3. Running pnpm 11, which satisfies the advertised range, exposes an unreviewed dependency-build decision during installation.This report does not claim the pinned pnpm 10.18.3 CI configuration fails.
Environment and reproduction
v24.19.011.19.0The install exits 1 and reports:
It adds a pending decision to
pnpm-workspace.yaml:This placeholder is documented pnpm behavior, not accidental configuration corruption. A contributor following the broad minimum-version requirement nevertheless needs an extra policy decision that the quickstart does not explain.
Local remedy tested, with limits
For pnpm 11.19.0, adding this to the existing workspace configuration made the same frozen install succeed and run esbuild postinstall:
pnpm checkpassed across the workspace, including a fresh recheck on September 14 UTC. The existingminimumReleaseAge: 10080was unchanged. This approves esbuild scripts by package name, not just version 0.27.7, and does not authorize other packages.This is not proposed as a universal fix for the current version range:
allowBuildswas introduced in pnpm 10.26.0, after the repository/CI pin of 10.18.3. I have not tested the remedy under that older pinned version.Suggested resolution
Please choose and document one consistent policy:
Approving esbuild is a tested local option, not the only permissible security decision. The issue is the mismatch between the advertised contributor range and the pinned/tested workflow.
All reproduction work used local checkouts. No CALL-E API request or phone call was made. This report, the local reproduction and the proposed configuration change were prepared with substantial OpenAI Codex assistance under the account owner's direction.