corepack seems to obey LOCALAPPDATA silently

Platform : WSL2

If because of reasons you have WSLENV=WT_SESSION:WT_PROFILE_ID:LOCALAPPDATA/p:USERPROFILE/p:APPDATA/p to pass through LOCALAPPDATA & APPDATA to your WSL2 environment then you get permissions errors when trying to use yarn + corepack

bsh ❯ corepack enable
bsh ❯ COREPACK_ENABLE_DOWNLOAD_PROMPT=0 yarn install
node:internal/fs/promises:783
  return await PromisePrototypeThen(
         ^

Error: EACCES: permission denied, rename '/mnt/c/Users/.../AppData/Local/node/corepack/v1/corepack-774055-2af6683f.7bd48' -> '/mnt/c/Users/.../AppData/Local/node/corepack/v1/yarn/4.7.0'
    at async Object.rename (node:internal/fs/promises:783:10)
    at async renameSafe (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:21935:5)
    at async installVersion (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:21903:5)
    at async Engine.ensurePackageManager (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:22323:32)
    at async Engine.executePackageManagerRequest (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:22423:25)
    at async Object.runMain (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:23110:7) {
  errno: -13,
  code: 'EACCES',
  syscall: 'rename',
  path: '/mnt/c/Users/.../AppData/Local/node/corepack/v1/corepack-774055-2af6683f.7bd48',
  dest: '/mnt/c/Users/.../AppData/Local/node/corepack/v1/yarn/4.7.0'
}

This never used to happen, and I'm not sure if it's 'yarn' or 'corepack' that is the issue (there aren't any PRs or issues that mention appdata that seem related).

My current workaround is to use direnv to unset both those environment variables

@quotidian-ennui

@quotidian-ennui

This sounds like it is a configuration issue with WSL2 that you have already resolved with your workaround, not a bug in Corepack or Yarn.

If you think it is a bug in Corepack, I suggest you re-run your commands with DEBUG=corepack enabled and post the results here:

corepack enable yarn
export DEBUG=corepack
COREPACK_ENABLE_DOWNLOAD_PROMPT=0 yarn install

Please mention also which Linux distro you are running in WSL2.

See README > Troubleshooting.

I agree that it's not a technical bug in corepack (or yarn); however, it is an edge case that deserves to be documented. I wouldn't have raised it if there was obvious documentation about "what environment variables will always override the default location for cache storage" (or whatever this is); there isn't, or it wasn't obviously searchable.

Happy for you to close this as you see fit; it's here so that it's not some xkcd#959

I don't know about "silently", the README says this:

corepack/README.md

Lines 334 to 335 in 19e3c68

    
           - `COREPACK_HOME` can be set in order to define where Corepack should install 
        
             the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack`

But anyway, I agree we could try to improve the error output and/or the README to help users with this issue, PRs welcome

I tried setting WSLENV=WT_SESSION:WT_PROFILE_ID:LOCALAPPDATA/p:USERPROFILE/p:APPDATA/p in Windows 11 then running the following in Ubuntu 24.04.2 LTS under WSL2 with corepack@0.32.0:

cd $(mktemp -d)
rm -rf $LOCALAPPDATA/node/corepack
rm -rf ~/.cache/node/corepack
corepack enable yarn
export DEBUG=corepack
corepack use yarn@latest

$ echo $WSLENV
WT_SESSION:WT_PROFILE_ID:LOCALAPPDATA/p:USERPROFILE/p:APPDATA/p
$ corepack enable yarn
export DEBUG=corepack
corepack use yarn@latest
Installing yarn@4.7.0 in the project...
  corepack Installing yarn@4.7.0 from https://repo.yarnpkg.com/4.7.0/packages/yarnpkg-cli/bin/yarn.js +0ms
  corepack Downloading to /mnt/c/Users/mikem/AppData/Local/node/corepack/v1/corepack-312-d744b221.5bf8 +10ms
  corepack LastKnownGood file would be located at /mnt/c/Users/mikem/AppData/Local/node/corepack/lastKnownGood.json +424ms
  corepack No LastKnownGood version found in Corepack home. +4ms
  corepack Download and install of yarn@4.7.0 is finished +0ms
  corepack Checking /tmp/tmp.cPqWVAxuCz/package.json +0ms

➤ YN0000: · Yarn 4.7.0
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: · Done in 0s 36ms

I see that Corepack is using LOCALAPPDATA even though it is running under Ubuntu. I would have expected it to ignore that environment variable. Normally I would expect Corepack to act like it is running in a pure Linux environment, and ignore the fact that this is a virtual Linux running under a Windows host. So now I do think that it is a Corepack bug.

corepack/README.md

Lines 334 to 337 in 19e3c68

    
           - `COREPACK_HOME` can be set in order to define where Corepack should install 
        
             the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack` 
        
             on Windows, and to `$HOME/.cache/node/corepack` everywhere else.

This is also reproducible in a pure Ubuntu environment with no WSL2 involved.

If LOCALAPPDATA is defined under Ubuntu, then Corepack is using it to build the cache location.

To reproduce on Ubuntu:

npm install corepack@latest -g
mkdir $HOME/localappdata
export LOCALAPPDATA="$HOME/localappdata"
rm -rf $LOCALAPPDATA/node
rm -rf ~/.cache/node
cd $(mktemp -d)
corepack enable yarn
export DEBUG=corepack
corepack install -g yarn@latest
find $LOCALAPPDATA
find ~/.cache/node

Logs

Installing yarn@4.7.0...
  corepack Installing yarn@4.7.0 from https://repo.yarnpkg.com/4.7.0/packages/yarnpkg-cli/bin/yarn.js +0ms
  corepack Downloading to /home/mike/localappdata/node/corepack/v1/corepack-4798-871d3ee9.a67eb +1ms
  corepack LastKnownGood file would be located at /home/mike/localappdata/node/corepack/lastKnownGood.json +343ms
  corepack No LastKnownGood version found in Corepack home. +1ms
  corepack Download and install of yarn@4.7.0 is finished +0ms
  corepack LastKnownGood file would be located at /home/mike/localappdata/node/corepack/lastKnownGood.json +0ms
  corepack No LastKnownGood version found in Corepack home. +0ms
  corepack Setting yarn@4.7.0 as Last Known Good version +0ms
  corepack LastKnownGood file would be located at /home/mike/localappdata/node/corepack/lastKnownGood.json +1ms
/home/mike/localappdata
/home/mike/localappdata/node
/home/mike/localappdata/node/corepack
/home/mike/localappdata/node/corepack/lastKnownGood.json
/home/mike/localappdata/node/corepack/v1
/home/mike/localappdata/node/corepack/v1/yarn
/home/mike/localappdata/node/corepack/v1/yarn/4.7.0
/home/mike/localappdata/node/corepack/v1/yarn/4.7.0/.corepack
/home/mike/localappdata/node/corepack/v1/yarn/4.7.0/yarn.js
find: ‘/home/mike/.cache/node’: No such file or directory

@quotidian-ennui

@quotidian-ennui

Although I'm able to reproduce Corepack using the wrong cache directory under a pure Linux environment, I wasn't able to reproduce your Error: EACCES: permission denied error on rename. When I set the LOCALAPPDATA directory to read-only, I got a user-friendly error message. I see you were using Node.js 22.14.0, so I assume that you were using the bundled Corepack 0.31.0.

The rename error is in any case a separate issue, and the title of the issue here is "corepack seems to obey LOCALAPPDATA silently".

That's cool, I feel the ENOACCESS error is down to the very specific way NTFS is setup round here (something blah blah AD permissions not inherited by WSL2 something something), and it's a red herring.

I agree that your investigations (thanks!) show that the problem is LOCALAPPDATA being used regardless of platform. WSL2 should be treated as vanilla linux by corepack.

I've got a usable workaround (I'm not a nodejs dev by trade) so it's not breaking my workflow which is mostly AWS CDK.

@quotidian-ennui

@quotidian-ennui

Great to hear you have a useable workaround!

It seems the error is in

corepack/sources/folderUtils.ts

Lines 14 to 24 in 19e3c68

    
           export function getCorepackHomeFolder() { 
        
             return ( 
        
               process.env.COREPACK_HOME ?? 
        
               join( 
        
                 process.env.XDG_CACHE_HOME ?? 
        
                   process.env.LOCALAPPDATA ?? 
        
                   join(homedir(), process.platform === `win32` ? `AppData/Local` : `.cache`), 
        
                 `node/corepack`, 
        
               ) 
        
             ); 
        
           }

where process.env.LOCALAPPDATA is used if it is defined, no matter which operating system is running.

npm, pnpm and Yarn all are using LOCALAPPDATA only on Windows.

kinda unrelated, but we ran into this as we were settings XDG_CACHE_HOME to handle where puppeteer was saving its crashpads with chromium, setting COREPACK_HOME got our location to win

@Aschenbath

@Aschenbath

I see that you are submitting multiple PRs. You may want to check with @aduh95 if they are still considering new PRs before you continue to put effort into fixing issues. He is effectively the only maintainer who is still active here.

#687 discusses some of the background where pnpm and Yarn are both moving on to different ways of installing package managers.

Navigation Menu

Repository navigation

corepack seems to obey LOCALAPPDATA silently #673

Logs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	- `COREPACK_HOME` can be set in order to define where Corepack should install
	the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack`

	- `COREPACK_HOME` can be set in order to define where Corepack should install
	the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack`
	on Windows, and to `$HOME/.cache/node/corepack` everywhere else.

	export function getCorepackHomeFolder() {
	return (
	process.env.COREPACK_HOME ??
	join(
	process.env.XDG_CACHE_HOME ??
	process.env.LOCALAPPDATA ??
	join(homedir(), process.platform === `win32` ? `AppData/Local` : `.cache`),
	`node/corepack`,
	)
	);
	}

corepack seems to obey LOCALAPPDATA silently #673

Description

Activity

MikeMcC399 commented on Mar 17, 2025

quotidian-ennui commented on Mar 17, 2025

aduh95 commented on Mar 17, 2025

MikeMcC399 commented on Mar 17, 2025

MikeMcC399 commented on Mar 17, 2025

MikeMcC399 commented on Mar 17, 2025

Logs

MikeMcC399 commented on Mar 18, 2025

quotidian-ennui commented on Mar 18, 2025

MikeMcC399 commented on Mar 18, 2025

MikeMcC399 commented on Mar 18, 2025

phyzical commented on Sep 19, 2025

Aschenbath commented on Oct 19, 2026

MikeMcC399 commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions