Fix nvm use "exit status 1: Access is denied" on Windows

TL;DR#

nvm use on nvm-windows (the Windows-only tool, not the macOS/Linux nvm) switches Node.js by deleting and recreating a directory symlink with mklink /D. Windows refuses that unless the shell is elevated or Developer Mode is on, and it also refuses a non-admin write under C:\Program Files, where the 1.1.x installers put the symlink by default. nvm prints the child process status, exit status 1, followed by the Windows message.

Fix it by running nvm use once in an administrator PowerShell or Command Prompt (the switch persists), or permanently by enabling Developer Mode and moving the symlink to a folder you own such as C:\nvm4w\nodejs, or by upgrading. On 1.1.8 or 1.1.9, the versions behind most of these reports, any 1.x release from 1.1.10 on brings the UAC prompt back; nvm-windows v2 drops the admin requirement altogether.

The error, as posted on Stack Overflow by a Windows 10 user who had removed an earlier Node.js install before setting up nvm:

PS C:\Users\laveen> nvm install 14.18.1
Downloading node.js version 14.18.1 (64-bit)...
Complete
Creating C:\Users\laveen\AppData\Roaming\nvm\temp
 
Downloading npm version 6.14.15... Complete
Installing npm v6.14.15...
 
Installation complete. If you want to use this version, type
 
nvm use 14.18.1
PS C:\Users\laveen> nvm use 14.18.1
exit status 1: Access is denied.

The asker adds that it works in PowerShell run as administrator, but not in the VS Code terminal, where yarn is then unusable. Both halves have the same cause.

Why nvm use needs rights that nvm install does not#

The two commands write to different places.

• nvm install downloads Node.js into the nvm root. In the log above that is C:\Users\laveen\AppData\Roaming\nvm, a folder inside the user's own profile, so no special right is needed. The 1.1.x installer defaults the root to the roaming AppData folder (installer script, tag 1.1.8).
• nvm use does not copy anything. It points one fixed folder, the one named by the NVM_SYMLINK environment variable and placed on the system PATH by the installer, at the chosen version. The 1.x source of the use command removes the old link with rmdir, then runs mklink /D from the symlink path to the version folder, both through cmd /C.

The nvm-windows README states the requirement directly: "Remember when running nvm install or nvm use, Windows usually requires administrative rights (to create symlinks)." For nvm install that only applies when the root itself sits in a protected folder; the symlink is what nvm use touches. The Common Issues wiki page, the page the last 1.x builds point to (through a bit.ly link) when removing the old link is denied, and the maintainer's replies in the tracker, point to two separate Windows checks:

1. The right to create a symlink at all. The wiki: "Windows requires elevated administrative privileges to create symlinks, but developer mode eases these restrictions."
2. The right to write in the folder that holds the link. The 1.1.x installers suggested C:\Program Files\nodejs as the symlink folder (it is the default in the 1.1.8 installer script and in the other 1.1.x scripts checked); the current 1.x installer defaults to C:\nvm4w\nodejs (1.2.2 installer script). The wiki states the rule for the Node installation root ("Windows requires administrative privileges to write to C:\Program Files"), and the maintainer applies it to the symlink in issue #755: "admin privileges aren't required to execute node, but they've always been required to switch the active version if you use a Windows protected directory (like C:\Program Files\Nodejs)."

Where the words "exit status 1" come from#

nvm-windows is written in Go. Its run helper starts the command, captures standard error, and on failure returns the process error, a colon, then whatever the command wrote to stderr. In Go, a process that ended with code 1 formats as exit status 1 (Go source, os/exec_posix.go). So the message is two pieces glued together: cmd /C returned 1, and Windows wrote "Access is denied." The wiki says the same in plain words: "These come straight from Windows, indicating the user account does not have permissions to do what you're trying to do."

Why it used to work without admin#

Up to 1.1.7, nvm-windows raised a UAC prompt to elevate the mklink call. The maintainer, in issue #755, says the change since 1.1.7 "is that the UAC prompt is no longer triggered." From 1.1.8 (released September 2021, less than three months before the Stack Overflow question), the wiki records: "By popular demand, NVM4W 1.1.8 introduced support for developer mode. In other words, you won't receive a UAC prompt to elevate permissions if it's not explicitly necessary." In the reports on 1.1.8 and 1.1.9, without Developer Mode and without an elevated shell, the call fails instead of prompting. Issues #700, #717, #755 and #780, opened between November 2021 and March 2022, are all this same report.

That silent failure was limited to 1.1.8 and 1.1.9. The 1.1.10 release notes (November 2022) say: "Many users have requested UAC prompts be reinstated. NVM4W attempts to run commands without elevation. If this succeeds (i.e. developer mode is enabled and active), the process continues without prompts. If a command fails, an attempt to run it with elevated privileges will trigger the UAC prompt." On those later 1.x releases the same Windows refusal leads to a UAC prompt instead of an immediate failure.

What Windows refuses, reproduced#

nvm-windows 1.x itself was not run here: its installer requires administrator rights, and its elevate script falls back to a Windows "runas" request when the plain command fails, neither of which an unattended test can answer. The two Windows checks it depends on were reproduced directly, in a non-elevated PowerShell on Windows 11 (build 26200) with Developer Mode off, on 22 October 2026. The machine's UI language is French, so the messages are French. On an English system the first message contains "not have sufficient privilege", the text the nvm 1.x source tests for before it retries mklink, and the second is "Access is denied."

### Process elevated: False
### Developer Mode (AllowDevelopmentWithoutDevLicense): not set (OFF)
### 1. directory symlink in a user-owned folder (the call nvm use makes)
> cmd /C mklink /D nodejs-link v22.0.0
Vous ne disposez pas de privilèges suffisants pour effectuer cette opération.
exit code: 1
### 2. write under C:\Program Files (parent of the 1.1.x default NVM_SYMLINK)
> cmd /C mkdir "C:\Program Files\nodejs-probe"
Accès refusé.
exit code: 1
### 3. negative control: junction in the same user-owned folder
> cmd /C mklink /J nodejs-junction v22.0.0
Jonction créée pour nodejs-junction <<===>> v22.0.0
exit code: 0

Both refusals end with exit code 1, the number nvm prints. The negative control shows that a folder you own is not the problem: a junction in the same place succeeds without the symlink privilege. nvm-windows 1.x deliberately uses symlinks, not junctions: the wiki's "Why won't NVM4W support junctions?!" section explains that junctions do not work on the mapped and network drives many enterprise users install to.

Fix#

1. Check which nvm you have and where the link lives#

In PowerShell:

nvm version
$env:NVM_SYMLINK

On 1.1.11 or later (README), nvm debug also reports whether the shell is elevated and, in a non-admin shell, whether Developer Mode is on (a "Windows Developer Mode:" line reading ON or OFF). If NVM_SYMLINK starts with C:\Program Files, Developer Mode alone will not help, and you need step 2, 3 or 5.

2. Quick fix: run nvm use once from an elevated shell#

Right-click Windows PowerShell or Command Prompt, choose Run as administrator, and run:

nvm use 14.18.1

This is what the top answers on the question say, and it is enough on its own. The README explains why you do not have to repeat it in every window: "When you do run nvm use x.x.x, the active version of node is automatically updated across all open console windows. It also persists between system reboots, so you only need to use nvm when you want to make a change." You only go back to an admin shell to switch versions.

3. On 1.1.8 or 1.1.9: upgrade to get the UAC prompt back#

If nvm version prints 1.1.8 or 1.1.9 (the question was asked in December 2021, while 1.1.8 was the current release), install a newer 1.x release from the releases page. The installer runs as admin. From 1.1.10 on, nvm use in a normal terminal retries the failed command elevated and Windows shows a UAC prompt; accept it and the switch completes. You still answer a prompt on every switch, so step 4 is the way to stop needing admin at all.

4. Stop needing admin: Developer Mode plus a user-owned symlink folder#

1. Turn on Developer Mode, as Microsoft documents in Developer Mode. The maintainer, in issue #755, calls it "the only non-admin way to be granted permissions to create symlinks without UAC prompts".
2. Move the symlink out of Program Files. The simplest way on 1.x is to run the latest 1.x installer again (release 1.2.2) and, on the page that asks where to create the symlink, choose a folder that does not exist yet, such as C:\nvm4w\nodejs (the 1.2.2 default). The README's upgrade notes say to keep the same symlink folder; here you change it on purpose, and the installer rewrites both the path: line of settings.txt and NVM_SYMLINK. It writes NVM_SYMLINK for the machine and for your user, and the PATH entry it adds refers to %NVM_SYMLINK%, so the new location takes effect in new terminals. The installer runs as admin, but only this once. The README warns that the folder must not already exist: "NVM's generated symlink will not overwrite an existing (even empty) installation directory."
3. Remove what is left at C:\Program Files\nodejs from an elevated prompt: the old nvm link (rmdir removes a directory symlink without touching its target) or a real folder from an earlier Node.js install, which the README asks you to delete. If an old PATH entry still points there, the old link would keep resolving to the old version.

Developer Mode on its own is not always enough, and the issue tracker shows why: in issue #717, users with Developer Mode on still got "Access is denied", and the maintainer replied by pointing to the wiki: Windows protects some directories, such as C:\Program Files, even with Developer Mode enabled. His reply is about writing Node.js into a protected folder; a symlink kept in the same folder meets the same protection.

5. Or upgrade to nvm-windows v2#

nvm-windows has been rewritten. The project README lists, under Compatibility: "No mandatory administrator privileges." It adds a shim mode with no symlinks, and a link mode using "junctions with symlink fallback". The v2 overview says link mode is kept for legacy use while bypassing the permission model of v1. The v1 wiki now points v2 questions to that documentation site. If you are on a locked-down corporate machine where neither admin nor Developer Mode is available, v2 is the route that does not depend on either.

Verify the fix#

Open a new, non-elevated terminal (a fresh VS Code terminal is a good test) and run:

nvm current
node -v
Get-Item $env:NVM_SYMLINK | Format-List LinkType, Target

node -v should print the version you selected, and Get-Item should show LinkType : SymbolicLink with a Target inside your nvm root, for example C:\Users\you\AppData\Roaming\nvm\v14.18.1. If node -v still shows an older version, another Node.js install earlier on PATH is winning; the README calls this a PATH conflict and nvm debug flags it.

The VS Code and yarn half of the question#

The asker's second symptom, yarn not working in VS Code, has two parts.

First, VS Code cannot elevate for you. The maintainer, closing issue #780: "VS Code won't run anything as an admin unless it is opened with an account that has admin privileges." On 1.1.8 and 1.1.9, which never prompt, nvm use typed in the VS Code terminal therefore fails unless Developer Mode and a user-owned symlink folder are in place (step 4). From 1.1.10 the retry raises a UAC prompt from the VS Code terminal too (step 3). After a successful switch in an admin shell, close and reopen the VS Code terminal; if nvm was installed while VS Code was open, restart VS Code so it picks up the PATH entry.

Second, global tools belong to one Node version. Each version nvm installs gets its own global packages, and the README says global utilities "will have to be done for each installed version of node", using yarn as its example:

nvm use 14.18.1
npm install -g yarn

A freshly installed Node 14.18.1 has no yarn until you do this, even once the symlink problem is solved.

When elevating does not fix it#

A few reports in the tracker still fail from an admin shell. They have different causes, worth ruling out:

• The link folder is a real directory. If NVM_SYMLINK points at a folder that exists and is not a symlink (often a leftover C:\Program Files\nodejs), the 1.x source stops with "NVM_SYMLINK is set to a physical file/directory at" followed by the path. Delete or rename that folder, or pick another location.
• The current version is in use. The wiki lists exit 145 ("The directory is not empty") and exit 32 ("being used by another process") when a terminal or Explorer window sits inside the version folder, or a node process is still running. Close it, cd C:\, and retry.
• Alias bug in 1.1.8. In issue #700, where an admin shell did not help with nvm use lts, the maintainer confirmed a bug with the lts, latest and newest aliases and released the fix as 1.1.9. Pass an explicit version number instead, or upgrade.
• Unsupported terminal. The wiki states only CMD and PowerShell are officially supported, and some other shells do not respect UAC prompts.

If the error changes after the switch#

A successful nvm use often uncovers the next problem, because the project now runs on a different Node. Native modules compiled for the old version break first: node-sass, for example, fails with "could not find a binding for your current environment", covered in Node Sass could not find a binding, where the fix is a rebuild under the new Node or a move to Dart Sass. Going the other way, back to Node 12 or older, newer tools refuse to load: tsc SyntaxError: Unexpected token '?' is a recent TypeScript compiler loaded by a Node too old to parse it, and the Next.js 15 minimum Node.js version build error is the same mismatch for Next.js. On macOS or Linux, where the separate nvm project is the usual fix for global-install permission errors, see npm EACCES without sudo.

The short version: "Access is denied" from nvm use is Windows refusing either the symlink privilege or a write to Program Files, never a problem with the Node download. One elevated nvm use gets you working today; Developer Mode with a symlink folder you own, or nvm-windows v2, stops it coming back.