[Bug]: global pnpm installations cannot self-update

[oliver-mee]

Client or integration

Other: OpenCodex CLI (ocx)

Area

Installation or packaging

Summary

When OpenCodex is installed globally with pnpm, ocx update invokes the npm-oriented staging command. The pnpm CLI rejects the forwarded --allow-scripts, --no-audit, and --no-fund options, so the update aborts after the proxy has been stopped. The expected behaviour is for the updater to detect pnpm and use a pnpm-native global update path, or report a safe actionable error before stopping the proxy.

Reproduction

1. Install OpenCodex globally with pnpm: pnpm add -g @bitkyc08/opencodex.
2. Use an installed version for which a newer package is available.
3. Run ocx update.
4. Observe that the update is redirected to pnpm with npm-only flags and fails with unknown-option errors.

Version

2.46.0

Operating system

Ubuntu Linux on arm64 (exact distro release not recorded)

Provider and model

N/A, this is an installation and packaging issue.

Logs or error output

[npm-guard] global 'install' -> pnpm add -g --allow-scripts=bun --no-audit --no-fund @bitkyc08/opencodex@...
[ERROR] Unknown options: 'allow-scripts', 'audit', 'fund'

Screenshots and supporting files

None.

Redacted configuration

No configuration is required to reproduce this beyond a global pnpm installation.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[Ingwannu]

The pnpm-managed layout needs an explicit updater path, and PR #4203 now tracks that work. One distinction in the supplied log: [npm-guard] shows a host wrapper translating an npm invocation into pnpm, so that exact unknown-flags output should not be claimed for every stock pnpm installation without a wrapper-free control. I requested a correction in #4203 because its shared dependency verifier also loosens npm's pre-existing candidate-tree checks. Keeping this issue open; no live global install, update, stop, or restart was run.

[lidge-jun]

리뷰 · 우선순위 58 / 80

pnpm 으로 전역 설치한 ocx 가 ocx update 를 하면 npm 전용 스테이징 플래그를 그대로 넘겨 pnpm 이 거부합니다. 더 날카로운 점은, 실패하기 전에 프록시를 이미 멈춘다는 것입니다. 업데이트는 안 되고 서비스만 내려갑니다.

현재 dev HEAD 6101140ff(2.51.0) 의 src/update/transactional-install.mjs 는 스테이징에서 runNpm(["install", "-g", "--prefix", stageRoot, "--allow-scripts=bun", "--no-audit", "--no-fund", spec])(~:185) 를 씁니다. pnpm 은 이 옵션들을 모릅니다. 패키지 매니저 감지 후 pnpm-native 경로를 쓰거나, 프록시 stop 이전에 “이 설치는 pnpm 이라 이 updater 경로를 쓸 수 없다”고 실패해야 합니다. packaging 수정이고 product lane 과는 별개지만, stop-before-fail 때문에 운영 체감 우선순위는 중간 이상입니다.

라인 - src/update/transactional-install.mjs ~:185 — --allow-scripts=bun --no-audit --no-fund 를 runNpm 에 전달; pnpm 거부
경로/심볼 - transactional-install.mjs runNpm 주입 — pnpm 감지·pnpm-native global update 분기 없음
경로/심볼 - update 흐름 stop-proxy-before-stage — 스테이징 실패 전에 프록시가 이미 중지되는 순서(이슈 재현의 sharp edge)

메인테이너의 판단이 필요한 지점

• pnpm 전용 transactional 경로를 구현할지, 감지 시 stop 전에 명확한 unsupported 에러만 낼지
• bun/npm/pnpm 설치 경로를 한 detector 로 통일할지
• stop-proxy 순서를 “스테이징 성공 확정 후”로 바꿀지(권장 검토)

너의 추천
pnpm 을 감지해 pnpm-native 전역 업데이트 경로를 쓰거나, 지원 전이면 프록시를 멈추기 전에 실패하세요. 지금은 stop-proxy-before-fail 이 가장 위험한 부분입니다. npm 전용 플래그를 pnpm 에 넘기지 마세요.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Fixed on dev via #4235 at 55c74ac (carried from #4203).