[BUG] `Cannot read properties of undefined (reading 'binPaths')` when trying to use `npx` with workspaces and `install-strategy=linked`

[james-pre]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

I have a monorepo with workspaces set up (here). In it, I have two bins configured:

1. In the root package.json, I have "bin": { "axium": "server/dist/main.js" }.
2. In server/package.json, I have "bin": { "axium": "dist/main.js" }

No matter what, npx axium gives the following error:

npm warn reify The "linked" install strategy is EXPERIMENTAL and may contain bugs.
npm error Cannot read properties of undefined (reading 'binPaths')
npm error A complete log of this run can be found in: /home/jp/.npm/_logs/2026-04-08T20_06_05_367Z-debug-0.log

I've tried this in the project root, in the server workspace, and in other workspaces. All exhibit the same error.

In CI/CD, I get a different error when trying to use npx axium:

npm warn reify The "linked" install strategy is EXPERIMENTAL and may contain bugs.
npm warn tarball tarball data for @axium/server@file:../../../../../work/axium/axium/server (null) seems to be corrupted. Trying again.
npm warn tarball tarball data for @axium/server@file:../../../../../work/axium/axium/server (null) seems to be corrupted. Trying again.
npm error code ENOENT
npm error syscall open
npm error path /home/work/axium/axium/server/package.json
npm error errno -2
npm error enoent Could not read package.json: Error: ENOENT: no such file or directory, open '/home/work/axium/axium/server/package.json'
npm error enoent This is related to npm not being able to find a file.
npm error enoent
npm error A complete log of this run can be found in: /home/runner/.npm/_logs/2026-04-08T14_13_15_797Z-debug-0.log

Pulled from this Github Actions workflow run

Expected Behavior

npx should work correctly, even when install-strategy=linked is used.

Steps To Reproduce

1. Create a monorepo using workspaces
2. Use install-strategy=linked
3. Define a bin for a file in one of the workspaces
4. Attempt to use npx ... with the defined bin

Environment

• npm: v11.12.1
• Node.js: v24.13.1
• OS Name: Fedora Linux 43
• System Model Name: N/A
• npm config:

; "user" config from /home/jp/.npmrc

//registry.npmjs.org/:_authToken = (protected)

; node bin location = /usr/bin/node-24
; node version = v24.13.1
; npm local prefix = /home/jp
; npm version = 11.12.1
; cwd = /home/jp
; HOME = /home/jp
; Run `npm config ls -l` to show all defaults.

I believe this may be related to #9166/#9167. I opened a new issue since that one is a defect with npm link while this issue deals with npx and shows a different error for local paths as well.

[manzoorwanijk]

Can you try again from the latest branch? I think this might be already fixed by #9167.

[james-pre]

Hey @manzoorwanijk, I am still seeing this issue with npm 11.13.0 (which has #9167 from @npmcli/arborist@9.4.3).

[manzoorwanijk]

Hey @james-pre, thanks for confirming this is still happening on 11.13.0. The CI-side ENOENT you saw earlier was #9166, which is fixed by #9167 - but the local Cannot read properties of undefined (reading 'binPaths') crash is a separate issue I haven't been able to reproduce yet from the description alone.

To help us pin it down, could you share:

1. The full debug log - the file referenced in your error output (/home/jp/.npm/_logs/2026-04-08T20_06_05_367Z-debug-0.log or whatever the latest one is). The stack trace in there will tell us exactly which of four candidate call sites is firing. You can paste it inline, attach it as a .txt, or upload to a gist.

2. The state of node_modules/ right before the failing npx run. Specifically:

   ls -la node_modules
   ls -la node_modules/.store 2>/dev/null | head -50
   ls -la node_modules/.bin 2>/dev/null
   find . -maxdepth 3 -name node_modules -not -path '*/node_modules/*/node_modules/*'

3. The exact command sequence that triggers it from a clean state. For example:

   git clean -fdx
   npm install
   npx axium

   Does the crash happen on the first npx axium after a fresh npm install, or only after some other operation?

4. Whether it reproduces with --ignore-scripts. That tells us whether postinstall scripts (e.g. sharp, patch-package) are involved:

   git clean -fdx
   npm install --ignore-scripts
   npx axium

5. Which specific bin you're running. The issue body shows you have axium in both root and server/- does it also crash when you run npx axc or npx axium-client (defined only in the client workspace)?

The debug log alone is probably enough - items 2–5 are just useful if the log doesn't have a stack trace. Thanks!

[james-pre]

Hey @manzoorwanijk,

here's the stack trace:

TypeError: Cannot read properties of undefined (reading 'binPaths')
    at /usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js:391:18
    at Array.forEach (<anonymous>)
    at processDeps (/usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js:390:18)
    at processEdges (/usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js:434:9)
    at [createIsolatedTree] (/usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js:443:5)
    at async Arborist.reify (/usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/reify.js:139:24)
    at async exec (/usr/local/lib/node_modules/npm/node_modules/libnpmexec/lib/index.js:293:7)
    at async Npm.exec (/usr/local/lib/node_modules/npm/lib/npm.js:208:9)
    at async module.exports (/usr/local/lib/node_modules/npm/lib/cli/entry.js:67:5)

Also npm exec appears to not be using install-strategy=linked though despite it's presence in .npmrc.

[james-pre]

Okay I figured I'd take a look at this more...

I found that for some reason my local install of npm still had @npmcli/arborist v9.1.2.

I did sudo npm rm -g npm and sudo npm-24 i -g npm which resulted in @npmcli/arborist v9.4.3 being installed, and now the issue appears to be fixed.

I'm not sure why an outdated dependency version still existed, it may be worthwhile to updated the minimum required version in dependencies so that an updated version is used.