Safeguard
Developer Tools•

Open VSX namespaces and the unverified publisher warning

On Open VSX, creating a namespace does not make you a verified owner. See how namespaces, owner rights and the publisher warning work when choosing.

Safeguard Security Team
3 min read

On Open VSX, the open extension registry, creating a namespace does not make the publisher a verified owner. Extensions from a namespace without owner rights show the warning that the user account is not a verified publisher of the namespace. Treat that warning as a reason to look closer.

What a namespace is

An Open VSX extension has a name in the form namespace.extension, and the namespace comes from the publisher field in the extension's package.json. According to the Open VSX publishing wiki, the namespace must be created before publishing, and names may contain only letters, numbers and a few symbols. If creation fails, the namespace probably already exists and cannot be used.

Contributor versus owner

This is the part many readers miss. Per the wiki:

  • Creating a namespace gives you contributor rights, not ownership.
  • Without owner rights, the extension displays the warning "That user account is not a verified publisher of the namespace."
  • To remove the warning, the publisher must request owner authority through the namespace management process.

So the warning describes the relationship between the account and the namespace. It does not say the extension is malicious, and its absence does not prove the extension is safe.

Same name as a VS Code Marketplace extension

The wiki notes that if an extension has the same publisher and extension name as one on the VS Code Marketplace, you need owner rights to that Open VSX namespace to publish it. Otherwise it stays under review. That is a guard against someone publishing a lookalike under a well known name, though you should still check the publisher.

Publisher agreement and tokens

Publishers need an Eclipse account tied to the same GitHub username, and they must agree to the Publisher Agreement. Access tokens are shown once, and the wiki advises using a separate token for each environment, such as local machine, cloud IDE and CI. A token can publish any number of extensions until it is deleted, so leaked tokens matter. Publishers should keep them in a secrets store.

After upload, the extension is scanned and shows as Deactivated until processing finishes, typically within 5 to 10 seconds, per the wiki.

What to check as a user

  1. Look for the verified publisher warning on the extension page.
  2. Compare the publisher with the project's own website or repository.
  3. Apply the same checks as for any extension. See the vetting checklist.
  4. If your editor supports it, apply an allowlist of extension IDs.

Editors that use Open VSX may differ from VS Code in their settings, so check your editor's documentation before assuming the VS Code controls apply.

Why this matters beyond one extension

Extension registries are part of your software supply chain. Anyone can publish under a namespace they create, so the namespace is only as meaningful as the checks behind it. Owner verification is one of those checks, and the warning is the visible result. When your editor pulls from a registry like this, a lookalike name is a realistic way for unwanted code to reach a developer machine, which is why matching the publisher to the real project is worth the minute it takes.

Quick check

Does the warning mean an extension is malware?

No. It means the publishing account is not a verified owner of the namespace. Investigate further.

Does a missing warning mean it is safe?

No. Ownership verification is one signal. Still read reviews and source.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.