You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Include support for system-wide mandatory/default settings #27972
It is currently not possible for an administrator to define mandatory and/or default settings that apply to all users/workspaces. This would be very helpful in a corporate/enterprise setting where we want users to have a consistent experience, or where the infrastructure demands certain configs (e.g. "update.channel": "none").
Suggestion:
a) Define an environment variable that points to a json file with mandatory settings, which override user/workspace settings.
b) Define another environment variable that points to a json file with default settings, which get copied to the user settings file when a user launches vscode for the first time.
If suggestion a) is difficult to implement I will settle for b) and use an extension (e.g. Fetch User Environment) to manage the mandatory settings.
VSCode is great, but in managed environments the inability to provide and control default settings for all users is a big problem.
Reacted by Constantine, TwoXTwentyOne, hb9tst, Rhys Paterson, Onno Broekmans, Thomas Honeyman, Marcus Schweda, Luís Fonseca, Alberto Cavalcante, Friedrich Altheide and 2 more
A few weeks ago I intended to migrate from sublimetext to vsc, but this issue was a show stopper. For me (developer and administrator) it is unusable without default settings / the ability to be "installed" (for all users) by copying one single folder.
Reacted by TwoXTwentyOne, Rhys Paterson, Thomas Honeyman and Ernst Reissner
There also appears to be no simple way to install extensions for all users. On top of this, even the per-user offline extensions needs to be deployed as a subsequent step post-install:
Start-Process "VSCodeSetup-x64-1.19.2.exe" -ArgumentList /silent, /mergetasks='!runcode,addcontextmenufiles,addcontextmenufolders,addtopath' -Wait
# VISX files downloaded to \extensions in the installation root for offline install.
Get-ChildItem "$PSScriptRoot\extensions" | % {
Start-Process "C:\Program Files\Microsoft VS Code\bin\code.cmd" -ArgumentList "--install-extension $($_.FullName)" -Wait
}
But, log on as a different user and there are no extensions.
It would be great if the installer could automatically deploy these during the installation, or at least allow for a multi-user deployment of the extension. I think the Visual Studio VSIXInstaller.exe can/could do this with /admin? I appreciate a system-level / all users installation would prevent individual users from upgrading or managing the extension for themselves in the future, but in a managed development environment that's not such a bad thing (especially with additional security requirements such as white-listing). Even being able to point it to a local UNC share by default would be handy. Some development workstations don't have Internet access anyway.
Given this is replacing the PowerShell ISE in core 6+, it's so far looking pretty difficult to deploy this in large enterprise environments while retaining some manner of consistency.
Reacted by hb9tst, Raymond Gauthier, Brian Powell, Roger Lindholm, Thomas Honeyman and HunnyR
VS Code has become a very good and powerful development environment, much lighter than huge programs like the "real" Visual Studio or Eclipse. Unfortunately, the absence of system-wide configuration capabilities (and especially of system-wide extension installation) is a big problem for managed environments. Of course, everything can be done with appropriate login (or program startup) scripts, but I see that more like DIY rather than a professional solution. In my opinion, a system-wide configuration file and extension directory would be a very good starting point (GPO support would of course be welcome too... but this is less urgent).
Reacted by Rhys Paterson, Raymond Gauthier, Roger Lindholm, Thomas Honeyman and nzdudeinsydney
I installed powershell core and changed terminal.integrated.shell.windows to pwsh.exe but hitting F1
the Terminal: Select Default shell still shows the path to the powershell V1 exe.
Would like to be able to change terminal.integrated.shell.windows in default settings to use the new powershell.
Atm every time I switch between Wsl and back to powershell I have to update user settings to pwsh.exe again!
I'd also like to use VSCode natively installed on Windows 10 while editing and working on files in the WSL system without ruining my linux permissions etc. (we use Linux projects on GitHub). On my 8 GB ram laptop a Ubuntu VM runs kinda slow.
On NixOS we have the vscode-with-extensions,which allow to package VSCode with preinstalled extensions,but then you can't install extensions from the VSCode UI.
This is problematic as a few extensions needs to be fixed for use on NixOS,and this feature would allow to use extensions both from the nix store (with all the paths fixed) and the larger VSCode marketplace
Reacted by Alexey Raga, Daniel Goertzen, Valentin Robert, Jarosław Jedynak, Dan (Eli) Hastings, Martin Puppe, InLaw, Robert Hensing, Raymond Gauthier, Kyle Gentle and 6 more
If it's not feasible to have it roadmapped for the vscode team, is there anyone familiar with this part of the codebase who could provide guidance for how it might be implemented by an intrepid community member?
We run ~100 shared linux machines used by students and researchers. The ability to not override settings administratively is a huge impediment to wider use of vscode. We'd love to use this more heavily - especially with our CS students, but can't, due to this deficiency.
What remains to close this issue are the system-wide default settings, the mandatory parts are resolved for windows/mac/linux recently with Policy settings (aka. system-wide mandatory settings if I understand this correctly).
The issue title/description could benefit from an update to reflect this to help us focus the effort.
This feature is still of great interest to me. While the new policy.json file allows system-wide mandatory settings, the default settings feature is still missing and would be incredibly helpful in a managed environment. Preferably it would just add another layer to the existing settings.json scheme where each layer overrides the next (i.e. system > user > workspace > folder). The system settings.json file could be placed in /etc/vscode/settings.json for instance. This would be very similar to how git works with the same override scheme (system > user > repo) with a system defaults file in /etc.
Activity
kieferrm commentedon Jun 5, 2017
//cc Erich Gamma (@egamma)
HollisTech commentedon Nov 30, 2017
VSCode is great, but in managed environments the inability to provide and control default settings for all users is a big problem.
dibr0006 commentedon Dec 6, 2017
A few weeks ago I intended to migrate from sublimetext to vsc, but this issue was a show stopper. For me (developer and administrator) it is unusable without default settings / the ability to be "installed" (for all users) by copying one single folder.
rhyspaterson commentedon Jan 15, 2018
There also appears to be no simple way to install extensions for all users. On top of this, even the per-user offline extensions needs to be deployed as a subsequent step post-install:
But, log on as a different user and there are no extensions.
It would be great if the installer could automatically deploy these during the installation, or at least allow for a multi-user deployment of the extension. I think the Visual Studio VSIXInstaller.exe can/could do this with /admin? I appreciate a system-level / all users installation would prevent individual users from upgrading or managing the extension for themselves in the future, but in a managed development environment that's not such a bad thing (especially with additional security requirements such as white-listing). Even being able to point it to a local UNC share by default would be handy. Some development workstations don't have Internet access anyway.
Given this is replacing the PowerShell ISE in core 6+, it's so far looking pretty difficult to deploy this in large enterprise environments while retaining some manner of consistency.
hb9tst commentedon Feb 8, 2018
VS Code has become a very good and powerful development environment, much lighter than huge programs like the "real" Visual Studio or Eclipse. Unfortunately, the absence of system-wide configuration capabilities (and especially of system-wide extension installation) is a big problem for managed environments. Of course, everything can be done with appropriate login (or program startup) scripts, but I see that more like DIY rather than a professional solution. In my opinion, a system-wide configuration file and extension directory would be a very good starting point (GPO support would of course be welcome too... but this is less urgent).
timoline commentedon Jun 2, 2018
Any progess on this?
Like all above, it's hard (no way) to deploy VSCode in a large environment and have a manner of consistency.
HollisTech commentedon Sep 11, 2018
This feature request has been sitting here for over a year. Is this even difficult? How do we escalate issues?
devantic commentedon Jan 24, 2019
Problem for me too.
I installed powershell core and changed terminal.integrated.shell.windows to pwsh.exe but hitting F1
the Terminal: Select Default shell still shows the path to the powershell V1 exe.
Would like to be able to change terminal.integrated.shell.windows in default settings to use the new powershell.
Atm every time I switch between Wsl and back to powershell I have to update user settings to pwsh.exe again!
GreatTeacherOni commentedon Mar 28, 2019
I'd also like to use VSCode natively installed on Windows 10 while editing and working on files in the WSL system without ruining my linux permissions etc. (we use Linux projects on GitHub). On my 8 GB ram laptop a Ubuntu VM runs kinda slow.
pasqui23 commentedon Aug 14, 2019
On NixOS we have the
vscode-with-extensions,which allow to package VSCode with preinstalled extensions,but then you can't install extensions from the VSCode UI.This is problematic as a few extensions needs to be fixed for use on NixOS,and this feature would allow to use extensions both from the nix store (with all the paths fixed) and the larger VSCode marketplace
God-damnit-all commentedon Nov 23, 2019
A way to select the installation directory would also be nice.
2 remaining items
kylegentle commentedon Mar 24, 2021
Hi Kai Maetzel (@kieferrm) and Rachel Macfarlane (@RMacfarlane), what would it take to get this feature added to the roadmap?
If it's not feasible to have it roadmapped for the vscode team, is there anyone familiar with this part of the codebase who could provide guidance for how it might be implemented by an intrepid community member?
benwa commentedon May 19, 2021
We either need GPO support, or deployable json files that supersede user-configured settings.
PeterHodges15 commentedon Jul 22, 2021
Gosh, Every user, Every machine, Every Setting....
No global settings (or extensions/modules) is a burden.
mldailey commentedon Jul 22, 2021
We run ~100 shared linux machines used by students and researchers. The ability to not override settings administratively is a huge impediment to wider use of vscode. We'd love to use this more heavily - especially with our CS students, but can't, due to this deficiency.
gilescope commentedon Jul 30, 2021
Would microsoft accept a PR along these lines? (I'm assuming this is kinda run like an open source project)
joaomoreno commentedon Apr 27, 2022
Closing as duplicate of #147756
consideRatio commentedon Oct 28, 2025
What remains to close this issue are the system-wide default settings, the mandatory parts are resolved for windows/mac/linux recently with Policy settings (aka. system-wide mandatory settings if I understand this correctly).
The issue title/description could benefit from an update to reflect this to help us focus the effort.
dwhite5914 commentedon Apr 24, 2026
This feature is still of great interest to me. While the new policy.json file allows system-wide mandatory settings, the default settings feature is still missing and would be incredibly helpful in a managed environment. Preferably it would just add another layer to the existing settings.json scheme where each layer overrides the next (i.e. system > user > workspace > folder). The system settings.json file could be placed in /etc/vscode/settings.json for instance. This would be very similar to how git works with the same override scheme (system > user > repo) with a system defaults file in /etc.