Repository navigation
[Bug]: updater fails to locate npm-cli.js when npm is managed by pnpm #173
Description
Product or interface
CLI - interactive TUI
Version
0.4.12
Platform
macOS
OS version and architecture
macOS 27 arm64
Issue area
Startup / install / update
Desktop log upload ID (optional)
No response
Steps to reproduce
MiniMax Code is installed successfully and runs normally:
curl -fsSL https://filecdn.minimax.chat/public/install.sh | bash
mcode --version
0.4.12
However, when the updater tries to update MiniMax Code, it fails with:
mcode update
Cannot locate npm-cli.js for the owned npm executable: /Volumes/KIOXIA/Applications/tools/.pnpm-home/npm
npm/pnpm layout
My npm executable is managed by pnpm and is located at:
/Volumes/KIOXIA/Applications/tools/.pnpm-home/npm
The npm executable is a shell shim generated by pnpm:
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/nodejs/26.3.1/lib/node_modules/npm/bin/npm-cli.js" "$@"
else
exec node "$basedir/nodejs/26.3.1/lib/node_modules/npm/bin/npm-cli.js" "$@"
fi
The real npm CLI exists at:
/Volumes/KIOXIA/Applications/tools/.pnpm-home/nodejs/26.3.1/lib/node_modules/npm/bin/npm-cli.js
node -v
v26.3.1
npm -v
11.16.0
pnpm -v
10.32.1
Expected and actual behavior
The updater should either:
correctly resolve pnpm's npm shim to the real npm-cli.js, or
invoke the existing npm executable directly instead of assuming a particular npm filesystem layout.
Redacted error summary
Screenshots
No response
Before submitting
- I have searched existing issues.
- I have included my version and removed sensitive information.
Activity
hetaoBackend commentedon Sep 19, 2026
Thanks for the concrete pnpm shim and filesystem layout. The current updater resolves npm through a small set of conventional npm-cli.js locations, which does not cover the versioned path in your example. I've started an isolated fix with regression coverage for that layout, while preserving the updater's Node/runtime binding. I'll link the PR here after local validation; no new release is available from this investigation yet.
hetaoBackend commentedon Sep 19, 2026
The fix is now available for review in #177.
I reproduced the failure using synthetic directories matching the reported pnpm shim. The updater now reads the shim's literal, versioned npm CLI target without executing or sourcing the shell script, rejects ambiguous or escaping targets, and still invokes npm with the updater's selected Node. Existing ownership checks and conventional npm layouts are preserved.
Validation on commit
4547174aabbdb668914f21007c7ccae969d88f80: all 73 focused updater tests and the complete 14-gatepnpm verifyfull profile passed on macOS arm64 with Node 26.4.0 and pnpm 9.12.0. Tests include a synthetic npm CLI subprocess, regular symlinks, a Windows npm.cmd layout fixture, missing targets and symlink escapes.This is not a release yet. I did not run a real product upgrade, live registry acceptance, the exact reported OS/Node/pnpm combination, or local Windows/Linux execution. The PR remains open for review.
hetaoBackend commentedon Sep 19, 2026
CI update for PR #177 at
4547174aabbdb668914f21007c7ccae969d88f80: verification has now passed on Linux, macOS and Windows with Node 24, including the aggregateverificationcheck. The Source verification run and Release audit run both completed successfully; CodeQL checks passed as well. Final PR status: 11 passed, 0 failed, 2 skipped (docsand[code]smith), nothing pending.No additional code changes were needed. This adds cross-platform CI evidence; it does not establish a real product upgrade or live registry acceptance. The PR is still open and no release has been published.
hetaoBackend commentedon Sep 19, 2026
Source update: #177 has now been merged as
63e8d578dfb9f4fa7d86bcdb53bb7618792473e3. The validated fix is in the default branch. This confirms source delivery, not that an installed npm package has been updated; the exact reporter environment and a real product upgrade remain outside the completed validation. Keeping this issue open for release/reporter follow-up.rishu685 commentedon Sep 19, 2026
can i work on this issue now?
hetaoBackend commentedon Sep 19, 2026
@rishu685 Thanks for offering to help! The implementation for this specific bug is already covered by #177, merged on September 19 as
63e8d578dfb9f4fa7d86bcdb53bb7618792473e3and present on currentmain, so a duplicate fix PR is not needed.This issue remains open for release and reporter verification. I checked the public npm registry today:
@minimax-ai/code@latestis still 0.4.12, published on September 18. I also downloaded that version's tarball without installing/running it, verified its SHA-512 integrity, and inspected the bundled updater: it still only checks the conventional npm CLI locations and does not contain the pnpm shim fallback from #177. The merged source fix has therefore not reached this stable npm package yet.The useful remaining contribution is validation once a package containing #177 is available: confirm an installer-owned installation can use the reported pnpm-managed npm shim and complete an update with the intended Node runtime. The exact reported environment (macOS 27 arm64, Node 26.3.1, npm 11.16.0, pnpm 10.32.1) still needs confirmation. Existing regression tests and Linux/macOS/Windows CI passed, but they are not evidence of that real upgrade. Retesting the unchanged 0.4.12 package would still exercise the old updater.
If you find a distinct unsupported shim layout or a failure with the fixed source, please share a minimal reproduction, exact versions, and a sanitized shim/error here so we can scope follow-up work. No real product upgrade was performed in this follow-up; keeping the issue open pending a fixed release and verification.