# How to Publish a VS Code Extension: Marketplace, Open VSX and Launch Steps > How to publish a VS Code extension: publisher setup, vsce packaging, Marketplace and Open VSX uploads, the December 2026 token change and launch steps. - Canonical: https://zeroraised.com/blog/how-to-publish-a-vs-code-extension - Published: 2026-10-19 - Updated: 2026-10-19 - Author: Jay Mokashi (https://zeroraised.com/blog/authors/jaymokashi) - Publisher: ZeroRaised (https://zeroraised.com/) - Section: Growth - Tags: developer-tools, marketplaces, product-launch, launch-strategy 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](https://zeroraised.com/launch-sites/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. | Step | Tool or place | What you need | Common snag | |---|---|---|---| | Scaffold | `yo code` through npx | Node.js and the VS Code extension generator | `engines.vscode` must suit the VS Code you test in | | Describe | package.json and README.md | Publisher ID, display name, icon, repository, keywords | User-provided SVG images are refused; images need https links | | Package | `vsce package` | The vsce tool | Many small files load much slower than one bundle | | Create publisher | Marketplace publisher management page | A Microsoft account | The publisher ID cannot be changed later | | Authenticate | Azure DevOps | A token or Microsoft Entra ID credentials | Global tokens stop working on 1 Dec 2026 | | Publish | `vsce publish` | The signed-in publisher | Packages built on Windows lose the executable bit on files | | Mirror | Open VSX with `ovsx` | Eclipse account, signed agreement, namespace, access token | The namespace must exist before the first upload | ## 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](https://dev.to/nomnomhub/i-built-a-chat-network-that-lives-inside-vs-code-25io), 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](https://marketplace.visualstudio.com/items?itemName=SideChannel.sidechannel) (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](https://dev.to/saad-works/i-built-a-vs-code-extension-that-lets-you-read-books-as-source-code-50c0), 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](https://code.visualstudio.com/api/get-started/your-first-extension) begins: “First, use Yeoman and VS Code Extension Generator to scaffold a TypeScript or JavaScript project ready for development.” Nothing needs installing globally: ```bash 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](https://github.com/microsoft/vscode-vsce) 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](https://code.visualstudio.com/docs/configure/extensions/extension-marketplace) 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](https://code.visualstudio.com/api/working-with-extensions/publishing-extension) 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 `, 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.** ```bash 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](https://code.visualstudio.com/api/references/extension-manifest) 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](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate) 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](https://cursor.com/help/customization/extensions) 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](https://github.com/eclipse/openvsx/wiki/Publishing-Extensions) (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. ```bash npx ovsx create-namespace -p npx ovsx publish -p ``` 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. | Item | Visual Studio Marketplace | Open VSX | |---|---|---| | Who runs it | Microsoft, on Azure DevOps | The Eclipse Foundation manages the public registry at open-vsx.org | | Account | Microsoft account and a Marketplace publisher | eclipse.org account linked to the same GitHub login | | Identity | Publisher ID, fixed once created | Namespace matching your `publisher` field, created with ovsx | | Upload tool | vsce | ovsx (which uses vsce internally to package) | | Authentication | Azure DevOps token, Entra ID or GitHub trusted publishing | Open VSX access token | | Verification | Verified publisher: domain plus six months on the Marketplace | Claim namespace ownership; Cursor adds its own badge | | Used by | VS Code | Editors such as Cursor | ## Bundle the code and keep the extension light The [bundling guide](https://code.visualstudio.com/api/working-with-extensions/bundling-extension) 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](https://code.visualstudio.com/api/extension-guides/web-extensions) 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](https://code.visualstudio.com/api/references/activation-events) 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](https://code.visualstudio.com/api/extension-guides/telemetry) 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](https://zeroraised.com/blog/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.” | Action | How | What users see | Reversible? | |---|---|---|---| | Publish a release | `vsce publish` or upload the VSIX | Update offered to installed users | Ship a newer version | | Publish a pre-release | `vsce publish --pre-release` | Opt-in pre-release version | Publish a higher release or pre-release | | Share a test build | `vsce package`, send the VSIX | Manual install, auto update off | Testers uninstall it | | Remove one version | Publisher page, More Actions, Reports, Delete this version | That version disappears; the latest version cannot be deleted | No; the version number cannot be reused, so upload a higher one | | Unpublish | Publisher page, More Actions, Unpublish | No new downloads; statistics kept | The guide suggests it over removal | | Deprecate | Comment in the deprecated extensions discussion thread | Strike-through text, Migrate button if there is an alternative | Not covered in the guide | | Remove | `vsce unpublish publisher.name` or the publisher page | Gone, statistics deleted | No; the name is reserved permanently | If unsure, unpublish. You can remove later; you can never un-remove. ## Earn trust before you ask for installs The [extension runtime security page](https://code.visualstudio.com/docs/configure/extensions/extension-runtime-security) 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](https://code.visualstudio.com/api/working-with-extensions/continuous-integration) 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](https://zeroraised.com/blog/how-to-write-a-show-hn-post). - **The open source route**, if the repository is public. [How to market an open source project](https://zeroraised.com/blog/how-to-market-an-open-source-project) covers READMEs, contributors and developer communities. - **Developer-tool launch sites.** [DevHunt vs Product Hunt](https://zeroraised.com/blog/devhunt-vs-product-hunt) compares two common choices. Sibling guides on [how to launch a Chrome extension](https://zeroraised.com/blog/how-to-launch-a-chrome-extension) and [how to publish a Slack app](https://zeroraised.com/blog/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](https://zeroraised.com/) 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](https://zeroraised.com/submit). The [maker perks page](https://zeroraised.com/perks) 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. ## Frequently asked questions ### How do I publish a VS Code extension to the Marketplace? Scaffold and build the extension, fill in package.json with a publisher ID, display name, icon and repository, create a publisher on the Visual Studio Marketplace, sign the vsce tool in to that publisher and run vsce publish. You can run vsce package first to build a VSIX file and test it locally. ### What is Open VSX and do I need to publish there? Open VSX is an open extension registry managed by the Eclipse Foundation. Cursor uses it for third-party extensions, so an extension published only to the Microsoft Marketplace will be missing for those users. Publishing there needs an Eclipse account, a signed publisher agreement, a namespace and the ovsx tool. ### What changes for VS Code extension publishers on 1 December 2026? Azure DevOps retires global personal access tokens on 1 December 2026, and the older publishing steps create exactly that kind of token. The VS Code publishing guide recommends moving to Microsoft Entra ID based publishing, so update any CI job or local setup that relies on a global token before that date. ### Can I charge for a VS Code extension? The Marketplace lets you show a pricing label of Free or Trial in package.json and add a sponsor link, but the publishing guide describes no checkout. Any payment has to happen outside the Marketplace, for example through your own site, with the extension checking a licence or account. ### Can I unpublish or delete a VS Code extension? Yes. Unpublishing stops new downloads from the Marketplace and VS Code and keeps the extension statistics. Removing it deletes the statistics and permanently reserves the extension name, so it cannot be reused even by the original publisher. You can also deprecate an extension in favour of another extension or a setting.