When an Open VSX publisher requests revocation of their Publisher Agreement, the agreement is marked inactive, their personal access tokens are marked inactive, and every extension version they published becomes inactive. Inactive versions are hidden from the web interface, API and CLI. Signing a new agreement reactivates the old versions, but not the old tokens.
The sequence, step by step
The project's guidelines on revoking publisher contributions describe this flow:
- The publisher files a request as an issue in the open-vsx.org repository.
- The agreement is marked inactive in the Eclipse Foundation database, so it no longer authorises publishing.
- The publisher's personal access tokens are marked inactive in the open-vsx.org database.
- All versions they published are marked inactive. If every version of an extension is inactive, the extension is inaccessible.
What stays and what returns
| Item | After revocation | If a new agreement is signed |
|---|---|---|
| Publisher Agreement | Inactive | Active again |
| Personal access tokens | Inactive | Stay inactive, create new ones |
| Published versions | Inactive, hidden | Reactivated |
| Version numbers | Cannot be republished by anyone | Same |
The last row is a quiet integrity feature. No one can republish an existing version number, even an inactive one. An administrator must delete the inactive version before someone else can publish it. That stops a different party from slipping new content into an old version number that some machines may have pinned.
Why this is relevant to your team
If your developers install extensions from Open VSX, an extension can vanish from the registry without being malicious. A publisher may leave, or want contributions removed. For you that means:
- A pinned or recommended extension may stop being available for new installs.
- Offline mirrors and internal registries may keep serving a copy that upstream no longer lists.
- A copy that reappears later under a different publisher deserves suspicion.
This is a different problem from a takedown for malware, but the operational response is similar: you need to know which extensions are in use, where they came from, and who owns them.
A short procedure
- List the extensions your developers and build images use, with publisher and version.
- Mark which ones come from Open VSX and which from other sources.
- Decide which you will mirror internally, and with what review.
- Define a replacement process, so a revoked extension has an agreed substitute.
- Check namespace and publisher details when an extension changes hands.
The namespace verification state is worth looking at in the same pass. Open VSX also has a warning for unverified namespaces, which is covered in a separate post on namespaces and verified publishers.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory records source and version for each component, which is the record you need when something disappears upstream.
Safeguard ships an Open VSX extension for its own tools, and its SBOM and dependency scanning helps you keep the inventory part of this procedure current.
Quick check
Are revoked extensions deleted?
They are marked inactive and hidden. If the publisher signs a new agreement, the versions are reactivated.
Can someone else republish a revoked version number?
Not directly. An administrator must delete the inactive version first.
Do old tokens work again after reinstatement?
No. They stay inactive and the publisher must create new ones.
Sources
Last reviewed: 19 October 2026.
