Release, update and remove a plugin

Understand the approach

Choose a distribution channel for the intended audience: repository marketplace, admin-managed workspace publication, or public directory submission. These have different ownership, eligibility and consumer steps. This lab supplies a complete local marketplace and versioned package; the release guide shows the actual Git ref, consumer installation, update and removal flow rather than ending at a readiness record.

For a repository marketplace, test the exact package, commit the catalog and package, tag the tested revision, and publish through your normal repository process. Consumers add the Git source with --ref, inspect the marketplace and installed version, and test a new chat. A local tag or JSON validation is not distribution. A pinned source remains pinned when refreshed; rollback explicitly selects a known-good ref and repeats verification.

Workspace admins can publish a local plugin to chosen roles from the Personal plugin menu. Public publication instead uses the Plugins portal: upload an eligible ZIP, resolve findings, submit for review, then publish the approved version. The current portal rejects lifecycle hooks/app references, so this hook-bearing local lab cannot be submitted unchanged. No account publication was performed by the course author; the lesson still teaches the executable publisher and consumer path.

Prepare the right review evidence

For an MCP-backed submission, the current guide asks for five positive cases, three negative cases, a walkthrough, release notes, and a dedicated reviewer account when sign-in is required. Do not fabricate executed cases or create credentials for this lesson. A skills-only package can have a different requirement set. Mark every missing artifact and recheck the current portal guidance before requesting approval for a real submission.

Try it step by step

1. Finish the generated 0.3.0 extension, run the baseline/protocol checks and inspect the exact release files/license/setup instructions.
2. Rehearse native install/list/remove locally with the child-only helper; inspect the actual version and installed path.
3. For a repository you maintain, follow RELEASE.md to commit/tag/publish the tested marketplace; give consumers its real URL and pinned ref, not the tutorial placeholder.
4. Verify a consumer installation and actual workflow, then document explicit update/known-good rollback and removal. Keep shared marketplace dependencies in view.
5. If choosing workspace/public publication instead, follow its actual admin/portal steps and eligibility checks; verify visibility after publication rather than equating upload with availability.

A useful starting example

Illustration · adapt before use.

codex plugin marketplace add https://github.com/YOUR-ACCOUNT/YOUR-REPOSITORY.git --ref v0.3.0
codex plugin marketplace list --json
codex plugin add workflow-review-practice@howto-practice-local --json
codex plugin list --marketplace howto-practice-local --json
# After testing, remove only this practice installation/source:
codex plugin remove workflow-review-practice@howto-practice-local --json
codex plugin marketplace remove howto-practice-local --json

Check your result

• The actual versioned artifact passes behavioral and protocol checks, with native version receipts and cleanup.
• The selected channel includes concrete publisher and consumer steps plus update/rollback/removal.
• Local rehearsal, remote distribution, workspace visibility, public review and publication remain distinct states.

Common mistakes

• Claiming a local package or successful upload is publicly approved.
• Submitting hook-dependent or app-reference packages without checking current public-directory restrictions.