How to publish a VS Code extension to Open VSX

If you only publish to the VS Code Marketplace, every editor that is not allowed to use Microsoft’s gallery cannot see you. That is Cursor, Windsurf, VSCodium, Gitpod, Theia, and anything else that speaks the VS Code extension API under a licence that points at Open VSX.

On 6 September 2026 our crawl counted 13,461 extensions already on both registries (77% of Open VSX) and 3,968 on Open VSX only. 567 of the previous 30 days’ launches shipped to both from the start. Dual-listing is the default now, not a favour.

This is the publisher path. It is not Microsoft’s. The Eclipse Foundation runs the public registry; the steps below follow their docs.

1. Eclipse account, then the Publisher Agreement

You need an eclipse.org account with the same GitHub username you will use on open-vsx.org. Then:

1. Log in to open-vsx.org with GitHub.
2. Open your profile, click Log in with Eclipse, and authorise it.
3. Click Show Publisher Agreement, read it, Agree.

That agreement is not the Eclipse Contributor Agreement. The ECA is for contributing code to Eclipse projects and has no effect on whether you can publish an extension. The error “You must log in with an Eclipse Foundation account and sign a Publisher Agreement” means this step, not the ECA. The Foundation’s Open VSX FAQ is the canonical write-up; they also require every extension to ship under a licence.

2. Access token

Under Settings → Access Tokens, generate one per environment (laptop, CI, a second machine). The value is shown once. ovsx reads it from -p or from OVSX_PAT.

3. Create the namespace

The publisher field in package.json is the Open VSX namespace. Create it before the first upload:

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

Creating the namespace does not make you the verified owner. Listings in a namespace you only contribute to show a warning: the account is not a verified publisher of that namespace. Verified is a separate ownership request, described in what verified means. If the namespace already exists, you cannot take it — someone else started that process.

If the namespace matches your GitHub login, you can publish from the Open VSX UI and the namespace is created as part of that flow. Otherwise use the CLI or the registry API.

4. Package and upload

Same ovsx binary, internally wrapping vsce:

npx ovsx publish extension.vsix -p <token>

Or from the extension root, after npm install:

npx ovsx publish -p <token>

The public registry may scan the package on the way in: leaked secrets, a blocklist of known-bad files, and namespace-similarity checks against typosquatting. A rejection names the check. Fix the .vsix contents (usually .vscodeignore) and publish again.

The HaaLeo/publish-vscode-extension GitHub Action is the usual CI path. Put OVSX_PAT in the repo secrets next to VSCE_PAT.

Auto-publish is a fallback, not a strategy

open-vsx.org runs a service account that can republish Marketplace listings onto Open VSX from a nightly list. If you are the author, publish yourself. If you are not, the Eclipse wiki asks you to open an issue on the author’s repo first, then (only if they will not) add the id to open-vsx/publish-extensions. Auto-published copies are how a lot of the 13,461 twins exist. They also mean the Open VSX downloadCount can move when you are not the person who pushed the bits. Prefer a namespace you own.

After it is live

VSXRank will pick the listing up on the next Open VSX catalog pass (every four hours; the 04:00 UTC slot is the nightly one). Same publisher.name as the Marketplace listing is enough for us to show both columns on one page. You do not need to prove you publish it — there is no ownership check. Mark the watchlist row Mine if you want alerts on by default.

Open VSX numbers are downloads, including updates. Do not compare them to the Marketplace unique-install counter. Why they look inflated is the companion to this guide.

Official references: Publishing Extensions in the Open VSX wiki, and Managing Namespaces on the public registry wiki.