You spent hours curating your VS Code setup. Then a friend or colleague asks what you use. You could send them a screenshot and let them hunt for each extension by hand. Or you could hand them one command.
VS Code's Settings Sync exists, but it only syncs your own account across your own machines. It does not move your setup onto someone else's account on their machine. For that job, you need a different tool.
My own Windows migration kit already keeps VS Code's settings.json and keybindings.json synced through a dotfiles repo (a Git repository of config files). That system installs every app through Winget, the Windows package manager, and restores every config through symlinks. It never covered the extension list, because Winget installs applications, not VS Code extensions. That gap is what this command closes.
Exporting Your Extensions
On your machine, open a terminal and run one command. On Windows PowerShell, that command is code --list-extensions | % { "code --install-extension $_" }. On Mac or Linux, run code --list-extensions | xargs -L 1 echo code --install-extension.
What you get back is a self-contained script. Every extension you have installed becomes a single install command. The output looks like this:
code --install-extension Angular.ng-template
code --install-extension EditorConfig.EditorConfig
code --install-extension HookyQR.beautifyCopy the output and send it however you want: Slack, email, a text file, a GitHub gist. The commands stay portable no matter where they land.
Installing on the Other Side
Your friend opens their terminal, pastes the commands, and runs them. Every extension installs in sequence. It skips the part where someone types extension names from memory and gets them wrong. The whole process takes under a minute for a typical setup.
If the code command is not recognized on their machine, they need to register it first. Open VS Code, press Ctrl+Shift+P, type Shell Command: Install 'code' command in PATH, and run it. After that, the install commands work.
The List Belongs in the Dotfiles Repo
The real use for this command is standardizing a team. When you onboard someone onto a project, a shared extension list means everyone starts with the same linting and formatting support. That cuts out debugging sessions caused by one missing extension.
For a team, commit the extension list to the project repository as a text file, next to whatever else you already version-control. New developers clone the repo, run the commands, and start writing code with the right tooling already installed.
VS Code's built-in Profiles feature is the other way to share a setup.
The VS Code team demos Profiles, the built-in feature that bundles extensions and settings.
My own dotfiles repo tracks settings.json and keybindings.json for exactly this reason. The extension list was the one file it never had, until this command wrote it.
Related reading: GitHub Copilot Complete Guide, Plug N Play Software I Need on My New PC, The 2026 Content Stack - Three Tools to Win
