How to audit installed editor extensions across a dev team

To audit editor extensions, collect a list of installed extensions and versions from each developer, merge it into one inventory, rank each entry by publisher trust and need, then remove, pin or allowlist. The command line makes the collection step quick for VS Code and JetBrains IDEs.

Step 1: Collect the list

For VS Code, the documentation gives code --list-extensions, and adding --show-versions includes versions. Ask each developer to run it and send the output, or collect it through your device management tool.

For JetBrains IDEs, the Plugins settings page lists installed plugins under the Installed tab. Bundled plugins ship with the IDE and can be disabled but not uninstalled, so focus on the others, which come from JetBrains Marketplace, a custom repository or a local file.

If your team uses Open VSX compatible editors, the same idea applies using that editor's own list command or settings screen. Check its documentation, since this guide has not verified every editor.

Step 2: Merge into one inventory

Use a spreadsheet or a small script. For each extension record the ID, version, publisher, number of machines, and where it was installed from. Mark anything installed from a VSIX file or from disk, since those do not come through the usual Marketplace route.

Step 3: Score each entry

Use a simple four question score:

1. Is the publisher verified, and do you recognise it?
2. Is the extension actively maintained, with a source repository you can read?
3. Does the team need it, or does a built in feature do the same job?
4. How many people have it?

The vetting checklist gives the questions to ask about each one.

Step 4: Decide

• Keep and allowlist. Common, vetted extensions.
• Keep and pin. Extensions that touch sensitive code, with exact versions.
• Replace. Duplicates that do the same job.
• Remove. Anything unknown or unused.

Step 5: Enforce

For VS Code, extensions.allowed and the AllowedExtensions policy turn the decision into a rule. See the allowlist guide. For JetBrains, the idea.plugins.host property can point the IDE at a different default repository, which limits sources to the repositories you configure.

Step 6: Repeat on a schedule

Run the audit each quarter and when someone joins or leaves. A new starter often arrives with a long list synced from an old setup, so check what Settings Sync copies.

A small example

Imagine a team of twenty. The inventory shows eighty distinct extensions. Forty are installed on one machine each. A dozen overlap, such as three Markdown previewers. A few have no recent updates and no repository link. The audit does not need to be perfect to be useful: removing the unknown and the duplicates cuts the surface by half in an afternoon, and the allowlist keeps it from growing back.

What to tell the team

Explain the reason, not just the rule. Developers accept an allowlist when they understand that extensions run as them, with access to their keys, and when there is a quick path to request an addition. Pair the policy with a named owner and a response time.

Quick check

Sources

• Extension Marketplace, VS Code documentation
• Manage extensions in your enterprise
• Manage plugins, JetBrains documentation

Last reviewed: 19 October 2026.