How to Launch a VS Code Extension (2026)

Create a Publisher and Publish

A VS Code extension launch has two halves: getting a clean listing onto the Visual Studio Marketplace, then getting developers to it. If you've launched a Chrome extension, the shape is familiar, but the tools are different, and a few choices here can't be undone.

Everything runs through vsce, Microsoft's command-line tool for packaging and publishing extensions. Install it with npm install -g @vscode/vsce, then follow VS Code's publishing guide:

1. Create a publisher on the Marketplace management page, signed in with a Microsoft account. The ID appears in your extension's URLs and can't be changed later; the Name is what people see next to your extension.
2. Set publisher in package.json to that ID.
3. Run vsce package to build a .vsix file. Install it with Install from VSIX in the Extensions view and test it as a new user would.
4. Publish, either by uploading the .vsix on the management page or with vsce publish.

One change matters right now. Command-line publishing has long used an Azure DevOps personal access token, and Microsoft is retiring the global tokens it relied on. VS Code's docs give December 1, 2026; the Azure DevOps announcement has since moved the date to January 27, 2027. The recommended route is Trusted Publishing from GitHub Actions: create a policy on your publisher's Trusted Publishing tab naming your repository and workflow file, give the job id-token: write permission, and run npx @vscode/vsce publish --oidc. No token is stored anywhere.

Expect checks before you go live. The Marketplace scans every new extension and update for malware and won't make it public until the scan is clear, and it blocks publishing if it finds secrets such as API keys. vsce refuses a few things too: an SVG icon, SVG images in the README or CHANGELOG (badges from trusted providers aside) and image URLs that aren't https.

The Fields and README That Make Your Listing

Your Marketplace page is built from package.json and your README. The extension manifest reference lists every field; these shape the listing:

Write the description the way a developer would search. "Formats Terraform files on save and flags unused variables" gets found and read; "The best Terraform extension" doesn't.

The README is the listing page. It becomes the body of your Marketplace page and of the details page inside VS Code, shown alongside tabs for Feature Contributions (your commands, settings and shortcuts) and the changelog. Structure it like this:

1. One sentence on what it does and who it's for.
2. A GIF or screenshot of it working, near the top.
3. How to start: the command or shortcut to try first.
4. Settings, requirements and known issues.

If repository points to a public GitHub repo, vsce rewrites relative links in the README to it, using the main branch unless you pass --githubBranch. Add a CHANGELOG.md as well; our guide to writing a changelog applies directly. For the GIF, our guide to product demo videos covers keeping it short and clear.

Follow the Extension Guidelines

VS Code's UX guidelines describe how an extension should fit into the editor. Users notice when one ignores them, and uninstalling takes one click. The rules that matter most in launch week:

• Notifications: only when absolutely necessary, one at a time, each with a "Do not show again" option. The notification guidelines say not to use them for promotion or to ask for feedback on first install.
• Webviews: no promotions such as upgrades or sponsors, and don't open one on every update; the guidelines say to use a notification instead.
• Commands: clear names grouped under one category, no emojis, and never overwrite existing keyboard shortcuts.
• Status bar: short text, usually a single item, no custom colors.
• Onboarding: a walkthrough is the built-in way to show first steps. Keep it to a few.

Speed is part of good manners too. The activation events docs ask you to activate on every startup (*) only when nothing else works; onStartupFinished runs later without slowing startup. And bundle your code: one file loads faster than a hundred small ones, and only bundled extensions run in browser versions such as vscode.dev and github.dev.

Versions, Pre-Releases and Updates

The Marketplace accepts plain major.minor.patch versions; semver tags like -beta.1 aren't supported. vsce publish patch (or minor, or major) bumps the version and publishes, and inside a git repo it also creates a version commit and tag.

Pre-releases let early users get new builds first. Publish one with vsce publish --pre-release; users opt in from the dropdown on the Install button. Because VS Code always updates to the highest version, the publishing docs recommend even minor numbers for releases and odd ones for pre-releases, such as 0.2.x and 0.3.x, with engines.vscode set to 1.63.0 or later. It's a good home for the people from our guide to finding beta testers.

Three things to know before your first hotfix:

• Fixes don't arrive instantly. By default, VS Code waits 12 hours before installing an extension update automatically, unless the user clicks Update. Say so in the bug thread.
• Version numbers are spent once. You can delete a bad version on the management page, but you can't reuse its number, and you can't delete the latest version.
• Unpublish rather than remove. Unpublishing stops downloads and keeps your statistics. Removing is irreversible: it deletes the statistics and reserves the name forever, even from you.

Publish to Open VSX Too

Not every VS Code-compatible editor uses Microsoft's Marketplace. Open VSX is an open source registry for VS Code extensions, run by the Eclipse Foundation, that any editor supporting them can use. Its adopters include VSCodium, Gitpod and Coder. Skip it, and those users won't find your extension in their editor.

Open VSX asks you to use the same publisher and extension names as on the Marketplace, and once an extension is on the Marketplace, you need owner rights to the matching namespace before you can publish it. The steps, from the Open VSX publishing guide:

1. Create an Eclipse account, entering the GitHub username you'll use on Open VSX.
2. Sign in to open-vsx.org with GitHub, link your Eclipse account on your profile page, and sign the Publisher Agreement.
3. Generate an access token in your settings.
4. Create your namespace: npx ovsx create-namespace <publisher> -p <token>.
5. Publish the same .vsix: npx ovsx publish <file> -p <token>.
6. Claim the namespace through a GitHub issue, so your listing loses its "not a verified publisher" warning. Your GitHub account needs at least a year of history.

Open VSX scans uploads too, for leaked secrets, known-bad files and names too close to existing extensions, and a flagged upload stays under review until an admin looks at it. Publish to both registries from the same release workflow so they never drift apart.

Where to Find Your First Users

Publishing isn't a launch. In the Extensions view, people can sort results by installs or rating, according to the Extension Marketplace docs, and a new extension has neither yet. Your first users will come from places where developers already talk about the problem you solve:

1. Show HN. Extensions fit well: the Show HN guidelines are for things people can try, ideally without signups, and they ask you not to recruit upvotes. Read our Show HN guide first.
2. DevHunt, a weekly launchpad for developer tools where signed-in developers vote. Our review explains what a paid launch adds.
3. Communities for your language or framework. People who'd use a Terraform formatter gather in Terraform communities, not general ones. Read each one's self-promotion rules; our Reddit launch guide explains how, and r/SideProject and Indie Hackers welcome makers.
4. Launch boards with longer windows, such as Hauntboard, where a person reviews each launch, it spends 7 days in New this week, and its page views and visits are shown in public.

Make installing easy wherever you post. Give people the extension ID: typing @id:publisher.name in the Extensions view finds it directly. If a project you maintain benefits from it, add it to that repo's .vscode/extensions.json recommendations, so VS Code recommends it to everyone who opens the project. For one-to-one messages to developers who've described the problem, the outreach generator drafts the first one.

Ratings, Reviews and Trust

Developers check more than stars. VS Code's security guidance tells users to read Ratings & Reviews, see how responsive the publisher is in Q & A, and look for issues, repository and license links before installing. Since VS Code 1.97, installing from a third-party publisher for the first time also asks the user to confirm they trust that publisher. A real publisher name, a linked repository and quick answers all help at that moment.

• Ask after value, not on install. Once someone has used the extension a few times, one prompt with a "Don't show again" option respects both the guidelines and the user.
• Never buy or trade reviews. Ask real users for honest ones.
• Reply in public, fix in private. Microsoft's Marketplace publishing docs allow one reply per review and advise against using reviews as a support forum: point the reviewer to your issues page or email, fix the problem, then update your reply.
• Get verified later. The verified badge needs an extension on the Marketplace for at least 6 months and a domain registered for at least 6 months. You add a DNS TXT record, and the team replies within 5 business days.

A prompt that follows those rules:

Your publisher page shows each extension's acquisition trend and ratings, so check it weekly alongside your issues, and read what to do after launch day for the weeks that follow. Once your extension is live, launch it on Hauntboard for a permanent page that developers and search engines can find.