NVM blocked package-manager execution because the Node.js directory is unsafe

[jtabox]

❯ npm ls -g
NVM blocked package-manager execution because the Node.js directory is unsafe.

Path: C:\Progs\nvm\envs\v24.16.0
Reason: Directory is writable by other users.
Action: Reinstall this version into a private install root.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4305

❯ nvm list
  26.8.1
* 24.16.0  (default)

❯ nvm --version
v2.0.0

❯ nvm doctor
Verify cache
  Pubkey     : present (C:\Progs\nvm\.verify\pubkey.cer)
  HKCU cache : 3 entries at HKCU\Software\Author Software\Preferences\nvm\VerifyCache
    - C:\Progs\nvm\envs\v26.8.1\node.exe
    - C:\Progs\nvm\envs\v24.16.0\node.exe
  Mode       : accelerated (pubkey + HKCU cache)

Runtime ACLs
  InstallRoot: C:\Progs\nvm\envs
  DataRoot   : C:\Progs\nvm
  ShimDir    : C:\Progs\nvm\.shim
  Proxy      : C:\Progs\nvm\proxy.exe
  Tip        : run elevated `nvm doctor --autofix` to re-lock .shim/proxy DACLs
No checks directory found.

❯ gsudo nvm doctor --autofix
Verify cache
  Pubkey     : present (C:\Progs\nvm\.verify\pubkey.cer)
  HKCU cache : 3 entries at HKCU\Software\Author Software\Preferences\nvm\VerifyCache
    - C:\Progs\nvm\envs\v26.8.1\node.exe
    - C:\Progs\nvm\envs\v24.16.0\node.exe
  Mode       : accelerated (pubkey + HKCU cache)

Runtime ACLs
  InstallRoot: C:\Progs\nvm\envs
  DataRoot   : C:\Progs\nvm
  ShimDir    : C:\Progs\nvm\.shim
  Proxy      : C:\Progs\nvm\proxy.exe
  Repair     : re-applied managed DACLs and re-locked shim/proxy
No checks directory found.

❯ npm ls -g
NVM blocked package-manager execution because the Node.js directory is unsafe.

Path: C:\Progs\nvm\envs\v24.16.0
Reason: Directory is writable by other users.
Action: Reinstall this version into a private install root.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4305

I'm the only user in my PC, and the folder has the usual windows permissions, my user, Administrators, SYSTEM, and CREATOR OWNER

[ManguoLabsTech]

Root Cause

NVM v2.0.0 introduced strict DACL validation. Event code NVM4305 means the v24.16.0 directory has write permissions for groups like Users or Authenticated Users, not just your account. The nvm doctor --autofix only repairs shim and proxy DACLs, it does not touch version directories under InstallRoot.

Immediate Fix

Run elevated PowerShell to remove inherited permissions and grant exclusive access:

icacls "C:\Progs\nvm\envs\v24.16.0" /inheritance:r
icacls "C:\Progs\nvm\envs\v24.16.0" /grant:r "%USERNAME%:(OI)(CI)F"
icacls "C:\Progs\nvm\envs\v24.16.0" /grant:r "SYSTEM:(OI)(CI)F"
icacls "C:\Progs\nvm\envs\v24.16.0" /grant:r "Administrators:(OI)(CI)F"

Repeat for v26.8.1 if needed. Test with npm ls -g.

Verify Current Permissions

Check what NVM sees as unsafe:

icacls "C:\Progs\nvm\envs\v24.16.0"

Look for entries like BUILTIN\Users or NT AUTHORITY\Authenticated Users with (M) or (F) flags.

Prevention

If you reinstall versions, ensure InstallRoot itself has restricted DACLs before running nvm install:

icacls "C:\Progs\nvm\envs" /inheritance:r
icacls "C:\Progs\nvm\envs" /grant:r "%USERNAME%:(OI)(CI)F"
icacls "C:\Progs\nvm\envs" /grant:r "SYSTEM:(OI)(CI)F"
icacls "C:\Progs\nvm\envs" /grant:r "Administrators:(OI)(CI)F"

This ensures new version directories inherit safe permissions.

Notes

• The security model prevents privilege escalation if another local account exists or is added later

• Removing Users group write access is safe on single-user systems

• Check NVM event logs at C:\Progs\nvm\Logs if the issue persists after DACL corrections

If the commands resolve permissions but NVM still blocks execution, share the output of icacls "C:\Progs\nvm\envs\v24.16.0" and any new event codes from the logs.

[jtabox]

Yeah I don't know this new system seems more trouble than it's worth for me personally.

I uninstalled both environments completely, deleted the C:\Progs\nvm\envs folder completely, uninstalled nvm and run the installer again.

Then I ran your "Prevention" commands above, they were successful:

❯ icacls "C:\Progs\nvm\envs"
C:\Progs\nvm\envs BUILTIN\Administrators:(OI)(CI)(F)
                  NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                  PCNAME\username:(OI)(CI)(F)

I installed a new node.js, it worked, but only until I updated npm.

❯ nvm install 26.5.1

⠹ Installing 1 version: Waiting... 13s
Now using Node.js v26.5.1 by default.
Installed 1 version: 26.5.1
Completed in 13s

❯ npm ls -g
C:\Progs\nvm\envs\v26.5.1
`-- npm@11.17.0

❯ npm update -g --all
removed 8 packages, and changed 75 packages in 4s

15 packages are looking for funding
  run `npm fund` for details

❯ npm fund
NVM blocked package-manager execution because a delegated command could not be trusted.

Command: npm
File: C:\Progs\nvm\envs\v26.5.1\node_modules\npm\bin\npm-cli.js
Reason: delegated script changed since it was trusted
Action: Reinstall this Node.js version or run `nvm reshim` after a trusted install.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4306

❯ npm ls -g
NVM blocked package-manager execution because a delegated command could not be trusted.

Command: npm
File: C:\Progs\nvm\envs\v26.5.1\node_modules\npm\bin\npm-cli.js
Reason: delegated script changed since it was trusted
Action: Reinstall this Node.js version or run `nvm reshim` after a trusted install.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4306

❯ nvm reshim
All shims up to date.

❯ npm ls -g
NVM blocked package-manager execution because a delegated command could not be trusted.

Command: npm
File: C:\Progs\nvm\envs\v26.5.1\node_modules\npm\bin\npm-cli.js
Reason: delegated script changed since it was trusted
Action: Reinstall this Node.js version or run `nvm reshim` after a trusted install.
If this change was unexpected, contact your administrator and review NVM event logs.
Event code: NVM4306

I'm sure there's value for many users with this new system, but as a single user running stuff on my private PC, it isn't practical to have to fight with Windows file permissions. I'll probably go back to v1 for now, I haven't been able to use any node.js installation since I installed v2. Thanks for your help anyway.

[coreybutler]

Let me know if https://github.com/nvm-windows/nvm/releases/tag/v2.0.1-hotfix.1 resolves this.

[coreybutler]

@jtabox - I wanted to address your last comment. I completely understand the Windows permission battle (better than most). I know I just want the tools to get out of the way and let me work. That was and still is one of my top priorities with this project.

That said, there have been several security advisories filed against v1 related to unauthorized changes to Node. The DACL permissions were enforced in response to those advisories, which may still end up as CVEs issued against v1 (still determining that w/ researchers). Since agents are so capable of exploiting these, even on individual desktops, it's an issue we cannot ignore. Our solution was for the app to handle all of this for you, but you ran into an edge case with conflicting permissions between v1->v2 that we hadn't created in our lab (we have now).

It's worth noting that the issue you ran into only applies to shim mode (which is the new default). You could run nvm use link to apply legacy behavior similar to v1.x.x. See Operating Modes.

Link mode is much more flexible with permissions, but it is optional. Organizations that need to enforce stricter security can force shim mode through group policy (requires certified builds governance package). We could, conceivably, selectively enforce directory permissions in shim mode as a user configuration option while allowing organizations to force-enable it through the same group policy. I feel like this is not necessary right now since the hotfix should prevent the problem in the first place, but I'm explaining it here in case this pops up again for some reason or if folks have a compelling reason to disable DACL.

[jtabox]

@jtabox - I wanted to address your last comment. I completely understand the Windows permission battle (better than most). I know I just want the tools to get out of the way and let me work. That was and still is one of my top priorities with this project.

That said, there have been several security advisories filed against v1 related to unauthorized changes to Node. The DACL permissions were enforced in response to those advisories, which may still end up as CVEs issued against v1 (still determining that w/ researchers). Since agents are so capable of exploiting these, even on individual desktops, it's an issue we cannot ignore. Our solution was for the app to handle all of this for you, but you ran into an edge case with conflicting permissions between v1->v2 that we hadn't created in our lab (we have now).

It's worth noting that the issue you ran into only applies to shim mode (which is the new default). You could run nvm use link to apply legacy behavior similar to v1.x.x. See Operating Modes.

Link mode is much more flexible with permissions, but it is optional. Organizations that need to enforce stricter security can force shim mode through group policy (requires certified builds governance package). We could, conceivably, selectively enforce directory permissions in shim mode as a user configuration option while allowing organizations to force-enable it through the same group policy. I feel like this is not necessary right now since the hotfix should prevent the problem in the first place, but I'm explaining it here in case this pops up again for some reason or if folks have a compelling reason to disable DACL.

Thanks for replying.

I don't want to sound like I'm doubting your design choices (I'm not qualified to do so in any serious capacity anyway). As I wrote I'm sure this change has a reason and it's probably useful for most. And generally I appreciate the fact you've been providing this tool for free since forever, so I really don't want to sound ungrateful.

I'll try with the hotfix and if for some reason it doesn't work, I'll swap to link mode.

[coreybutler]

@jtabox I didn't get the impression you were doubting design choices, nor did it suggest ungratefulness. It came across as constructive feedback, which is helpful and appreciated. Thank you!

What I could say more directly is these choices/changes weren't supposed to cause any kind of disruption for users. The fact it did highlighted a bug. Bugs are fixable, and I believe this one is fixed now, so I'm still confident in the choice.

The suggestion for Link mode was merely meant to unblock you so you don't have to reinstall v1. But if the hotfix doesn't work in shim mode, please let me know, because it would mean we're missing something. I would want to address it.

[coreybutler]

I added many more permission handlers to identify these problems and resolve automatically in https://github.com/nvm-windows/nvm/releases/tag/v2.0.1-hotfix.2. I'm closing this issue under the assumption this is resolved. If it is not, I can certainly reopen the issue.