How to Publish a VS Code Extension: Marketplace, Open VSX and Launch Steps

How to publish a VS Code extension comes down to five moves: package it with the vsce tool, create a publisher on the Visual Studio Marketplace, authenticate through Azure DevOps, publish, then repeat the upload on Open VSX so editors such as Cursor can find it too. The upload itself is quick. What decides whether anyone installs the thing is the listing, the version plan and the trust signals around your publisher name.

Disclosure: ZeroRaised publishes this guide and appears in the final section. The steps follow the linked Microsoft, Eclipse and Cursor documentation as checked on 18 Oct 2026, and this guide makes no promise of installs, traffic or revenue from any registry or listing.

TL;DR#

The Marketplace upload is the short part. Most of the work sits in package.json, the README that becomes your store page, and a second upload to Open VSX, a separate registry with its own account and namespace. Publish only to Microsoft's Marketplace and Cursor users will search for your extension and not find it.

There is also a deadline. Azure DevOps retires global personal access tokens on 1 December 2026, and older tutorials (and the token steps still printed in the official guide) produce exactly that kind of token. If your setup came from one of those walkthroughs, move to Microsoft Entra ID or GitHub trusted publishing now, not after a failed release.

Plan your version numbers before the first upload, so a broken release can be fixed fast and a bad idea withdrawn without losing the name.

This week's example: a chat network shipped as a VS Code extension#

On 14 Oct 2026, a developer who signs off as Andrew and posts on DEV as Nom-nom-hub published “I built a chat network that lives inside VS Code” (DEV post, checked 18 Oct 2026). “So I built the thing I kept wishing existed: a chat network that lives in the VS Code sidebar.” Then the news: “It's called SideChannel, and it launched on the Marketplace this week.”

“You sign in with GitHub (the same login VS Code already has)”, so there is no new account, and you can “paste a stack trace and it strips secrets (keys, tokens, passwords) before posting.” “The extension is a webview client; the server is a small Node service with WebSockets and SQLite on a single VPS.” By Andrew's own estimate, “it costs about seven dollars a month to run, which is exactly how I want it.” The launch was capped: “the first wave takes 500 members, first come.” And Andrew is candid that the room starts empty: “The room is brand new and I'm not going to pretend otherwise; early rooms are where a community's culture gets set.”

What matters here is the record on the SideChannel Marketplace listing (checked 18 Oct 2026). Its version history shows 0.6.0 at 21:10 GMT on 14 Oct, 0.6.1 at 22:03 that evening, 0.7.0 at 11:35 on 15 Oct and 1.0.0 at 13:07 the same day. Four versions between one evening and the next afternoon. The listing settles the money question up front, “SideChannel is free, forever.”, says it “is supported by one small text advertisement at the bottom of the chat panel”, and tells users how to hide it: “Turn it off any time with sidechannel.showSponsor”.

One maker in one week is not a pattern, and none of this predicts how SideChannel will do. The narrower lesson: fast fixes only work if versioning, a changelog and authentication are sorted before the first upload.

Saad's post on 15 Oct 2026 introduces Plain Sight Reader, which opens PDF and EPUB books in an editor tab (DEV post, checked 18 Oct 2026). Its install line, code --install-extension saad-works.plain-sight-reader, shows the publisher-dot-name ID users type, which you fix for good when you create your publisher. Its privacy line is blunt: “No accounts, no telemetry, no network calls. Books stay on your machine.”

How to publish a VS Code extension, step by step#

If you searched for how to publish vscode extension to marketplace, this is the sequence.

1. Scaffold. Microsoft's first extension tutorial begins: “First, use Yeoman and VS Code Extension Generator to scaffold a TypeScript or JavaScript project ready for development.” Nothing needs installing globally:

npx --package yo --package generator-code -- yo code

Press F5 and the extension runs in a separate Extension Development Host window. If your command is missing there, the tutorial points at engines.vscode in package.json, which must be compatible with the VS Code you are running.

2. Install vsce. The vsce README asks for Node.js 22 or later. Install it with npm install -g @vscode/vsce or call it through npx.

3. Package and test locally. vsce package produces a .vsix file. Install it in your own editor first; the Marketplace documentation confirms “You can manually install a VS Code extension packaged in a .vsix file.” Note that “When you install an extension via VSIX, auto update for that extension is disabled by default.” Fine for a few testers, if you tell them to switch later.

4. Create a publisher. The VS Code publishing guide defines it: “A publisher is an identity that can publish extensions to the Visual Studio Code Marketplace.” You create one on the Marketplace publisher management page with an ID and a display name. The ID sits in every URL and install command, and the “ID cannot be changed once created.” Choose it like a domain name.

5. Authenticate. “Visual Studio Code uses Azure DevOps for its Marketplace services.” That means either a personal access token with the Marketplace Manage scope, used with vsce login <publisher-id>, or Entra ID credentials through vsce publish --azure-credential. The token route is what older tutorials describe, and it runs into the December change below.

6. Publish.

vsce publish

You can also upload the VSIX by hand on the publisher page. Pass major, minor or patch to bump the version as you go (vsce publish minor turns 1.0.0 into 1.1.0), and inside a git repository vsce also creates a version commit and tag.

One trap from the guide's troubleshooting notes: packages built on Windows lose POSIX file attributes such as the executable bit. If you ship a binary or script that must run, package on Linux, macOS or CI.

Get the listing right before the first publish#

Your package.json and README are the store page.

The extension manifest reference sets the rules. The icon is “The path to the icon of at least 128x128 pixels (256x256 for Retina screens).” Keywords help search, and “This list is currently limited to 30 keywords.” Categories come from a fixed list, so pick the one a user would browse. On copy: “Provide a good display name and description. This is important for the Marketplace and in product displays.” The same strings feed search inside VS Code, so use the words people type, not a slogan.

The publishing guide adds rules that block a publish outright. “Due to security concerns, vsce will not publish extensions that contain user-provided SVG images.” That covers the icon and README or CHANGELOG images, unless they come from a trusted badge provider. And “Image URLs in README.md and CHANGELOG.md need to resolve to https URLs.” A repository field pointing at a public GitHub repository lets vsce rewrite relative image links for you.

There is no checkout. You can show a pricing label, but “Allowed values are: Free and Trial (case-sensitive).” You can add a sponsor link to the details header. If you charge, payment and the licence check live on your own site and in your code, and the listing should say so before anyone installs.

Before the first upload, check that:

• publisher matches your publisher ID exactly;
• repository, bugs and a LICENSE file are present;
• the README opens with a GIF or screenshot of the extension doing its one job;
• a .vscodeignore keeps tests and local files out of the package.

Plain Sight Reader's post puts a demo GIF straight under its first paragraph, which beats a feature list.

The 1 December 2026 token change#

This is where older tutorials now go wrong. The publishing guide states: “On December 1, 2026, global Personal Access Tokens (PATs) in Azure DevOps are retired.” The Azure DevOps token documentation agrees: “All existing global PATs stop working on December 1, 2026.” (checked 18 Oct 2026).

The awkward part is that the token steps still printed in the VS Code guide tell you to choose “Organization: All accessible organizations”, which is a global token, and its troubleshooting notes list picking a single organisation as a common mistake. So the general Azure DevOps advice to move to organisation-scoped tokens is not obviously a drop-in fix for Marketplace publishing. Test before you rely on it.

The VS Code guide recommends Microsoft Entra ID based authentication with workload identity federation and managed identities, which removes the long-lived secret. In Azure Pipelines you add a managed identity as a member of your publisher and run vsce publish --azure-credential (vsce 2.26.1 or newer).

On GitHub Actions, the vsce README describes trusted publishing. You set a trusted publishing policy for the repository and workflow on the Marketplace, let the job request an OIDC token and run npx @vscode/vsce publish --oidc. The README says the session token lasts up to 15 minutes and that the command “does not fall back to a PAT” if the exchange fails.

This month, list every place a Marketplace token lives (your machine, CI secrets such as VSCE_PAT), move CI to Entra ID or trusted publishing, ship a patch through the new path and revoke the old token. Open VSX has its own tokens.

Publish to Open VSX as well#

Cursor's extension documentation is direct: “Cursor uses Open VSX for third-party extensions.” It adds that “Most popular extensions are available on Open VSX, but not every Microsoft Marketplace extension is listed there.” (checked 18 Oct 2026). Skip Open VSX and Cursor users cannot install your extension from inside their editor.

The second reason is your name. The same page warns: “The same publisher.extension name can point to different publishers or code on Open VSX than on the Microsoft Marketplace.” Its advice to users is “Treat extension IDs like dependencies: install from publishers you trust.” Claim your namespace on the Open VSX registry before someone else does.

The Open VSX publishing guide (checked 18 Oct 2026) has five steps:

1. Create an Eclipse account. “An eclipse.org account is necessary to sign a Publisher Agreement with the Eclipse Foundation.”
2. Log in to open-vsx.org with GitHub, connect the Eclipse account in your profile and sign the Publisher Agreement.
3. Generate an access token, one per environment.
4. Create the namespace matching your publisher field: “You need to create the namespace in the registry before any extension can be published to it.”
5. Upload the same VSIX you sent to the Marketplace.

npx ovsx create-namespace <name> -p <token>
npx ovsx publish <file> -p <token>

Two details catch people. “Creating a namespace does not automatically assign you as verified owner.” Claiming ownership is a separate request. And the registry can scan uploads for leaked secrets, known-bad files and names too close to existing extensions, so a stray API key gets the upload rejected. Cursor adds its own verification badge, which asks for a link to your Open VSX listing from a site on your own domain and the same extension ID on every marketplace.

Bundle the code and keep the extension light#

The bundling guide gives two reasons to bundle. Reach: “Only bundled extensions can be used in VS Code for Web environments like github.dev and vscode.dev”. And speed: “Loading 100 small files is much slower than loading one large file.” It suggests esbuild, which “is a fast JavaScript bundler that's simple to configure.” The generator asks which bundler you want when you scaffold, so choose there rather than retrofitting later.

If the extension should run in the browser, read the web extensions guide early: “For web extensions, the main entry file is defined by the browser property, and not by the main property as with regular extensions.”

Start-up cost is what users feel. The activation events reference explains: “Your extension becomes activated when the Activation Event happens.” Activating on * means activating whenever VS Code starts; the reference says onStartupFinished will not slow start-up and that several specific events beat *. Activate on your command, language or files.

Then decide what you collect. The telemetry guide offers the @vscode/extension-telemetry module, and if you roll your own, “it is still required that extension authors respect the user's choice by utilizing the isTelemetryEnabled” and onDidChangeTelemetryEnabled API. Many small extensions skip telemetry, as Plain Sight Reader does, and say so. Either way, state it in the README.

Versions, pre-releases and how to undo a release#

Learning how to release a vscode extension well is mostly about version numbers. The publishing guide says “We only support major.minor.patch for extension versions”, so semver tags like -beta.1 are out. Pre-releases are a channel instead: “To publish a pre-release version, pass the --pre-release flag to the vsce package or vsce publish commands”. Users opt in from the Install button's dropdown.

VS Code always updates to the highest version available, so a pre-release user jumps to a normal release if its number is higher. The guide's fix: even minor numbers for releases, odd for pre-releases, such as 0.2.x and 0.3.x. Pre-releases also need engines.vscode of at least 1.63.0, because they are only supported from that version onwards. Settle this before the first upload; renumbering later confuses everyone.

SideChannel's four versions in under a day show why: each needs a number, a CHANGELOG line and a way back. The guide on how to write release notes covers the CHANGELOG side.

When something goes wrong, you have options, and one is permanent. Unpublishing stops new downloads, and “When you unpublish an extension, the Marketplace preserves the extension statistics.” Removing deletes the statistics, and “Once an extension is removed, its extension name is permanently reserved and cannot be reused, even by the original publisher.”

If unsure, unpublish. You can remove later; you can never un-remove.

Earn trust before you ask for installs#

The extension runtime security page is plain about the stakes: “The extension host has the same permissions as VS Code itself.” It also describes the prompt every new publisher meets: “As of VS Code release 1.97, when you first install an extension from a third-party publisher, VS Code shows a dialog prompting you to confirm that you trust the publisher of that extension.” (checked 18 Oct 2026).

Your first conversion step is that dialog. The page tells users to check whether a publisher provides issues, a repository and a licence, and offers the support they expect. You can meet that on day one.

The blue check mark you cannot. “To become verified, a publisher must have one or more extensions on the VS Marketplace for a minimum of 6 months, and the registration of the domain must also be at least 6 months old.” Verification uses a DNS TXT record, and changing the publisher display name later revokes the badge. Until then the listing carries the weight: a public repository and licence, a line on what data leaves the machine, an honest limits section and an issue tracker someone reads.

Plain Sight Reader covers several of these. It explains that “The reader is a virtual document, so nothing gets written to your workspace and there is nothing to accidentally commit.” Its limits section opens: “Text extraction favours readability over exact layout.”

For workplace users, the Marketplace documentation describes an extensions.allowed setting: “If the setting is configured, all extensions not listed are blocked from installing.” Their administrator may need to add you, so explain code and network access in the README to keep that conversation short.

Automate releases with CI#

Publishing by hand invites mistakes. The continuous integration guide notes: “You can also configure the CI to publish a new version of the extension automatically.” Its examples publish only on tagged builds that pass their tests, a sensible default for a solo maker.

Those examples still store a secret, and “by default, vsce will use the VSCE_PAT environment variable as the Personal Access Token”. That is the secret to review before 1 December 2026: trusted publishing with --oidc on GitHub Actions, or --azure-credential on Azure Pipelines, removes it.

Run the Open VSX upload in the same job, right after the Marketplace step, with npx ovsx publish on the same VSIX and its own token secret. One tagged build feeding both registries keeps their versions in step.

After you publish: finding the first users#

The Marketplace is a search box, and a new extension with no installs or ratings sits behind established ones. As editorial judgement rather than a measured rule, the first users usually come from places where you already talk to developers. Both makers here acted that way: each wrote a post explaining why the extension exists and how to install it.

Routes that suit editor extensions:

• A Show HN or DEV post with the story behind the tool. See how to write a Show HN post.
• The open source route, if the repository is public. How to market an open source project covers READMEs, contributors and developer communities.
• Developer-tool launch sites. DevHunt vs Product Hunt compares two common choices.

Sibling guides on how to launch a Chrome extension and how to publish a Slack app cover those stores.

SideChannel's capped first wave suits a community product; it would be odd for a formatter. Use scarcity only when it is real.

Whatever the channel, answer three things quickly: what the extension does, how to install it (search term and full publisher.name ID), and what it does with the user's code. Then reply to every issue in the first weeks.

Where a launch listing fits once it is on the Marketplace#

A published extension gives you launch material: a working install link, a listing with screenshots, a repository and a CHANGELOG that shows movement. None of that guarantees anyone turns up.

ZeroRaised is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. If your extension is public and fits, you can submit it for review. The maker perks page is a separate resource for eligible makers. Neither replaces a clear listing or a quick reply to the first bug report.

So, how to publish a VS Code extension: a quick upload preceded by a handful of decisions about the publisher ID, the listing, the version scheme, the token setup and the second registry. Make those first, and the upload is the easy bit.