Change:
Permissions := '/grant:r "*S-1-5-18:(OI)(CI)F" /grant:r "*S-1-5-32-544:(OI)(CI)F" /grant:r "*S-1-5-11:(OI)(CI)RX" /grant:r "*S-1-5-32-545:(OI)(CI)RX"'; #if "user" == InstallTarget <del> Permissions := Permissions + ' /grant:r "*S-1-3-0:(OI)(CI)F"'; </del> <ins> Permissions := Permissions + Format(' /grant:r "*S-1-3-0:(OI)(CI)F" /grant:r "%s:(OI)(CI)F"', [GetUserNameString()]); </ins> #endif Exec(ExpandConstant('{sys}icacls.exe'), ExpandConstant('"{app}" /inheritancelevel:r ') + Permissions, '', SW_HIDE, ewWaitUntilTerminated, ResultCode);

Discussion:
Issue Type: <bBug</bWhen checking for updates, receive prompt saying the following: "C:UsersmyusernameAppDataLocalProgramsMicrosoft VS Code An error occurred while trying to create a file in the destination directory: Access is denied" Available options are: Try again Skip this file Cancel installation. First two options immediately bring prompt the error again, cancel installation suppresses it until auto-update re-attempts the installation. Error occurs when running as administrator as well. VS Code version: Code 1.66.1 (, 2022-04-06T14:50:12.141Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (1)</summaryExtensionVersion ------ prettier-vscode9.5.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The autoupdate kept failing and I figured "Oh, autoupdate is borked, let me just install the latest installer.." but nope, that fails too: !
now my install is corrupt, great: ! Error text if it helps:
I got the same error message after trying to upgrade via winget
Ditto here, but here the reported file is instead of
Here, the reported file is .
same issue here. started happening since yesterday.
Same issue, if i skip file it just keeps going through every single file.
Seems the permissions were borked on my install. I was able to fix it by changing the permissions. If you have administrator access with your user then you should be able to fix it with these steps: Step 1) Open CMD.EXE as administrator (with your user) Step 2) Run: Step 3) Run: If you don't have administrator then the easiest way to fix would be to have someone with administrator change the owner of folder, subfolder and files in %LOCALAPPDATA%ProgramsMicrosoft VS Code, using Windows Explorer's Properties Security Advanced. Once you are the owner you can run the command in Step 3 without administrator.
Thanks, Erijoda. This also fixed it for me.

:-) Step 3 for people with non-English Windows: icacls "%LOCALAPPDATA%ProgramsMicrosoft VS Code" /inheritance:r /remove "NT SERVICETrustedInstaller" /grant:r "%USERDOMAIN%%USERNAME%":(F) /grant:r "S-1-3-0":(OI)(CI)(IO)(F) /grant:r "S-1-5-32-545":(OI)(CI)(RX) /grant:r "S-1-5-11":(OI)(CI)(RX) /grant:r "S-1-5-32-544":(OI)(CI)(F) /grant:r "*S-1-5-18":(OI)(CI)(F)
Thank you it fixed it for me too. I was able to run the installer after your steps and my VSCode boots up like normal again.
What is the actual permissions difference between what VS Code set and what you set in that command? This is what VS Code is using today:
I just ran into this myself. I applied Full control to my user () with and got to the new error A did not help So I did to do the whole directory. That appears to have worked, and is hopefully a bit less invasive than the full replacement above.
Thanks This fixed it for me as well
will try this next time I face the issue
confirmed that running this from an admin cmd prompt fixed the issue icacls "%LOCALAPPDATA%ProgramsMicrosoft VS Code" /grant "%USERDOMAIN%%USERNAME%":F /T
This worked for me! Thank you !
This fixed my issue as well.

Thanks Step 1) Open CMD.EXE as administrator (with your user) Step 2) Run: takeown /F "%LOCALAPPDATA%ProgramsMicrosoft VS Code" /R /D Y Step 3) Run: icacls "%LOCALAPPDATA%ProgramsMicrosoft VS Code" /inheritance:r /remove "NT SERVICETrustedInstaller" /grant:r "%USERDOMAIN%%USERNAME%":(F) /grant:r "CREATOR OWNER":(OI)(CI)(IO)(F) /grant:r "BUILTINUsers":(OI)(CI)(RX) /grant:r "NT AUTHORITYAuthenticated Users":(OI)(CI)(RX) /grant:r "BUILTINAdministrators":(OI)(CI)(F) /grant:r "NT AUTHORITYSYSTEM":(OI)(CI)(F)
Just fyi - was closed as duplicate of this issue, but actually that problem seems different and is solved by simply running vscode as admin and then updating.
Apologies for not answering. I'm not a regular user at GitHub so missed the notification. It's been a while and I didn't save the original permissions on the folder but I think I can piece it together. The crux of the issue was as seen in the post That my user didn't have full access to the subfolders and files even though it was a user installed installation. So what I did was I compared the permissions in my broken install with a functioning install and made the command to fix the difference. Remove TrustedInstaller from the permissions and then add and replace the rest to get the same permissions as on a functioning installation of VS Code. The owner was different (possibly TrustedInstaller, but unsure) so that had to be changed before the permissions were corrected so the CREATOR OWNER would give full access to the correct user on the subfolders and files. So by the end there should be no difference in the resulting permissions and what you referenced in the above code.
My experience is that this doesn't solve the issue: once the permissions have become incorrect, it's no longer possible to upgrade from a non-elevated instance. Updating from an elevated instance is a mere workaround.
I am hitting a slightly different error. The same was reported in but then closed as duplicate of this issue:
I run into this with every update. It started to happen in April.

I'm logged into Win10 as Admin. I have to give the VSCode dir all the permissions I can to get it to complete, but the permissions get reverted by the next update, so must be done all over again. If I cancel the update, it attempts to roll back the changes but leaves me with a corrupt installation and the same missing module error as when trying to launch VSCode. So I think there's a separate issue with the roll back not working. To fix the missing module error, reinstalling VSCode works, but after that it still gives the permissions error at next update.
There are various workarounds posted in the thread (thanks!). Can someone on the VS Code team weigh in on which one we should be applying?
From what I can see, this issue is planned to be fixed in the
Hi all. I'm trying to (1) understand the issue fully and (2) to reproduce it locally. I still haven't been able to reproduce it locally. Quick questions for anyone who hit this issue: Do you usually OR have you recently ran VS Code as Administrator, using the User Setup? When you right click the VS Code installation folder (), select Properties, Security, does show up in the list? If you click Advanced, who is listed as the Owner? Is your machine domain joined?
Not always but for one repo I work in I run VS code as admin. Yes, is there; my domain account is listed as the owner. Yes, AAD joined. I'm MSFT-internal so feel free to ping me on Teams if you want to inspect my repro machine directly.
haven't ever run VS Code as an admin 've already run the workaround, but here's my info: Creator Owner does show up. There is no "Owner". I am listed as having Full Control for This Folder Only. Creator Owner has Full Control for Subfolders & files only account is AAD joined but my machine is not Domain Joined. I'm MSFT-internal as well. Feel free to reach out !
Add me to the list of Microsoft people who are experiencing this that you can ping . Do you usually OR have you recently ran VS Code as Administrator, using the User Setup?

No, I've never intentionally invoked something as Admin on this machine When you right click the VS Code installation folder (%localappdata%ProgramsMicrosoft VS Code), select Properties, Security, does CREATOR OWNER show up in the list? If you click Advanced, who is listed as the Owner? CREATOR OWNER is there The owner is my own domain account (redmondryanca) Probably relevant: Only the SYSTEM user and Adminstrators Group has Modify privileges on this folder Is your machine domain joined? Yes
I have one more question: anyone who saw this issue isn't MSFT?
I had to do this once and I remember vaguely that the issue with updates started soon after (soon enough to make me suspect it could be related). Yes, CREATOR OWNER is listed with full control over subfolders and files (but not this folder). My user is listed with full control over this folder only, and the owner is my user. All that said, I already tried several workarounds and was able to install an update (I think I did it from admin to make it work), so I am not sure I could repro anymore. Yes, to a Microsoft domain
I'm not and I was very surprised how many MSFT folks are hanging around here. Come to think of it, it makes a lot of sense, but still... :)
No (I'm logged in as Admin but I've only installed and launched Code normally) Yes, CREATOR OWNER shows up. I'm listed as Owner. It looks the same as PoulChapman's screenshot above, just without the Redmond No (well, I don't know what that is, so let's go with no) BTW looking in my I noticed I've got "update.enableWindowsBackgroundUpdates": false
, MSFT-internal here. No Me, but if I look at perms for a file that fails, it is Yes, to REDMOND.
Non-Microsoft employee. I do not run VS Code as administrator. I do install VS Code as administrator, using .  After answering the next question and noticing the owner, I ran as administrator to see if that would update without the error, and it worked. I am aware that there is a VS Code "user" install and "system" install.

I assume this is like other program installers that can install just for the current user or for all users on the machine. I never care, though, which way it is installed, as I am the only user. Nor have I ever needed to care [until now?]. I do not know which installer uses or if the VS Code installer does something different based on installing as admin. does show up in the list. The owner is listed as No. I script my entire machine setup. I run PowerShell as admin to execute the script. I'm pretty sure I started getting this error after I switched from scripted-download-and-install to . The way I used to do it (again, as admin): The way I do it now (again, still as admin): Perhaps my change to installing from is unrelated to the problem. Maybe not. It seemed worth mentioning. Thank you for looking into this.
It's not clear from your comments whether you hit this issue as well. Do you? Excellent! What file exactly? Mind sharing a screenshot of the Advanced view? correct! And it makes a huge difference in terms of the in-product update. If Code detects it was installed using the user setup, it will attempt an update without Admin permissions. So one should never install the User Setup as an Admin. Any chance you can switch your scripts to user the System Setup?
A blast of related? unrelated? information here. Sorry. I'm just using the command I showed. I assume that should handle installing correctly. (If that is an incorrect assumption, it looks like the VS Code winget manifest lists some different scopes I can pick from.) However, if VS Code installs using the system setup, and I don't normally run VS Code as admin, won't that have a problem when it needs to update? (IOW, won't it require admin privileges to update but not have them when VS Code is running?) I don't think I want to install and run VS Code as admin normally. When VS Code is running as admin, I can't open more than one instance. I get an error: It seems like the other option is to install as a non-admin. Though that doesn't seem very practical. I only run PowerShell as admin as it solves so many problems with commands not working.

(For example, want to ? You need admin. And so many more commands I've run into but forgotten over the years because I've learned to just run PS as admin.) I'm aware of with a trust level to unelevate a command but my efforts to use that in the past have been unfruitful. In the past when I downloaded and installed the user setup directly, that was also as admin, and I had no trouble then with VS Code updates. I'm not sure what to make of that. I'm happy to uninstall VS Code and reinstall using that method again to test and see if updates start working again but it takes a whole month to wait for the next update and try another setup variation. [Hm, unless I install a previous version? So it will always find the latest and attempt to update...? If I have a night this week to try this, I will.] If installing the user setup as admin, is there a reason it has to set the owner as Administrators? Can it set the owner as the user it is installing to? (Perhaps this is just a Windows thing that you have no control over?) FWIW, I don't have this problem with anything else I install from an admin PS session but run unelevated (Visual Studio, Discord, Steam and other game launchers, Edge Dev channel, etc). (Not saying that to complain - I'm sure I don't know how all of the elevated/unelevated interactions work.)
(not a Microsoft user ) Yes I sometimes run VS Code elevated when I develop PowerShell scripts that I presume an update took place upon exiting such an instance. Yes, is present. The owner is my MSA, which is a member of the local Administrators group (but I might have changed that during earlier troubleshooting of the issue). Nope.
The path throwing the access denied error on my end is "C:UsersXXXAppDataLocalProgramsMicrosoft VS Code.Npackd"
I just updated to 1.68.1, and it worked fine this time!
Solution by worked for me too and according to it works again on 1.68.1 but does not seem like it is fixed at will in that release according to release notes. So is this prevented to happen in future upgrades for good so tens of thousands of people are not down for several hours after trying to update?

I've tried changing the ACLs and owner, but that workaround didn't work. Lately - for every update - I just delete and re-install fresh. At one point I did enable controlled folders but that shouldn't have covered this location anyway. I disabled it a couple updates ago and, even after deleting the program folder, it still happens. But it happens every time with a different file, usually: Add me to the list of Microsofties you can ping internally for more details if you like. Alias is the same as my GitHub account. Update: after deleting the directory with elevated permissions and re-installing fresh, immediately after I ran on the program directory with the following results: Note that I don't have full permissions on subdirectories of the program root. The owner does, though, which is me. The file above, though - - does not exist after a fresh install. For subdirectories like bin I do see myself with full perms inherited ("(I)(F)") and "CREATOR OWNER" is there, also with fully inherited perms ("(I)(OI)(CI)(IO)(F)") but files within subdirectories like still show inherited full params for me ("(I)(F)"), but no "CREATOR OWNERS".
So is there a workaround? MSFTee here and blocked by the same issue.
! fixed for me. actually it didn't show any progression update window after click "Restart to Update"
Running from an admin command prompt fixed it for me.
Something like that worked once for me, but with the next update the problem occurred again. It's a workaround. Something is changing the ACLs, and seems to be happening only for VSCode. Other user-installed programs haven't exhibited this problem.
I just installed another successful update (1.69.0) without any workarounds (not even running it as admin). I think the issue may have been fixed in one of the most recent versions of VS Code.
Normally i manage everything through winget running as admin. I hit similar perms issues today moving from 1.68.1 to 1.69.0 with the error coming up as Access denied failed to write file to , and then following that a similar JS Runtime message to the one above.

Eventually i ended up: (via winget), removing the parent folder ( above) and (1.68 via winget) VScode as admin and using the inbuilt updater to get to 1.69.0 Note: Something really weird. Even after i had uninstalled it and removed all the folders. For some reason VScode was still running active processes. I had to go into task manager and manually end them, before it would let me reinstall.
This worked for me, but: should be if your account is member of a domain should be if your account is not member of a domain (the case for my home systems)
Another msft-ie here seeing the failure on both of my work machines: On my dev machine I may have tried running it as admin once, but not on my laptop (as far as I remember). Both are installed using the regular user installer (no winget, no admin). Yes, here are the permissions for the VS Code folder on my laptop: <img width="584" alt="image" src="https://user-"Also adding the permissions for the problem file (""): <img width="599" alt="image" src="https://user-"Yes for both affected machines.
It doesn't work. That one doesn't work as well. It should be , not . Are there ANY palns to make VS Code updates work again? Is this the intended workflow? Download default installer, choose Program Files, it installs the app, it fails to update, go to github, copy some commands, repeat every time you need to update. Is VS Code still in alpha, by any chance?
Hi all, sorry for the delay here. I got something for you. The problem, as some people pointed out, is related to the permissions left behind once the Setup finishes installing VS Code. Namely, the identity isn't working as we expected. Broken: ! By setting the for the current user, we should be able to create a good model upfront. I've created a build with that fix and ran extensive testing including with usernames with spaces and/or non-ASCII characters. Fixed: ! If you currently hit this issue, I'd appreciate it if you could download the following Insiders build, install it and show me your Advanced Security Settings dialog, so I can confirm things work fine in your setup?

Verification: the user setup of VS Code on the Advanced Security Settings of the directory that your user has access to and not just . Example: !
I presume the fix modifies existing installations on the next update, and doesn't only apply to fresh / new installations?
Correct, though it's possible that it might not be able to fix permissions on existing broken installations, given that's a chicken/egg problem. If you're hitting this issue, I'd suggest simply reinstalling on top of your installation (no need to uninstall first).
For you Microsofties that wanna debug this, or idk, have a soccer match between VS and Windows teams in the studios or something... Here's a list of the files that say "nope!" to permission updates if you're not in command line. Failed to enumerate objects in container. Access is denied. One invisible file b/c pathname is too long for dialog box. Has an underscore after the VS Code directory. Might literally be an underscore. EDIT: While I am unable to change permissions and am in correct directory, I had to modify the path variable used for another drive to successfully process the right directory. for the command(s) above due to installing on D: drive All of them say "access is denied" and error applying permissions. These are just quick notes I jotted during the four errors. Surprised they weren't mentioned above. They were skipped by the admin cmd line (I'm admin but not the super/sys admin you have to unlock on every device). I'm guessing if I login with the windows admin account itself, it will work... but.... who wants to have to go through that process every time. Not many normal users are aware that user admins aren't real admins. I'm not connected to any domains
Well, after all said and done... I ended up deleting the folder AppDataLocalProgramsMicrosoft VS Code and then i downloaded the latest version on vs code and install it... Everything works fine and i still get to keep my previous settings and extensions...