# Obsidian: The Future of Plugins

May 2026 launch post from the [[obsidian|Obsidian]] team announcing **Obsidian Community** — a new plugin / theme directory backed by a developer dashboard and an automated review system. The headline change is that *every release* now goes through automated review, not just the initial submission. The forcing function is volume: more than 4,000 plugins, 120M+ cumulative downloads, and coding-agent-accelerated submissions making the manual-review queue impossible to clear.

## What launched

- **[Obsidian Community](https://community.obsidian.md/)** — browsable directory, filtered/sorted views, per-project detail pages with screenshots, safety scorecards, paid / official labels. Author profile pages with sponsorship / social links.
- **Developer dashboard** — sign in with the new Obsidian account + GitHub. Submit plugins, manage existing projects, track release status. All existing plugins/themes and queued GitHub-PR submissions auto-migrated to the new system.
- **Automated review pipeline** — every version is scanned for security issues, code-quality regressions, known vulnerabilities, malware. Developers see warnings/errors in the dashboard.
- **Scorecards** — public per-project status. The roadmap adds capability disclosures, artifact attestation, manual-review results, and adoption of app capabilities.

Two qualifications worth keeping:

- Manual review continues, but reorientated toward *popular*, *featured*, and *community-flagged* plugins, instead of every first-time submission. The pipeline scales by automating the floor; humans cover the ceiling.
- Existing plugins that no longer pass the new review get a temporary exception — they stay listed for now. Eventually older plugins will have to meet the new standard or get phased out.

The 2,300+ queued submissions were cleared in the days before the launch. That number, plus the framing of "coding agents accelerate the creation of plugins", is the operational reason the old GitHub-PR pipeline broke.

## Submission flow

New flow ([[obsidian|Obsidian]] account + GitHub OAuth):

1. Sign in to community.obsidian.md
2. Connect GitHub, pick a repo
3. Complete dashboard steps (categories, screenshots, pricing label)
4. Submit — automated review runs immediately, typical result in minutes
5. Pass → searchable in the app within 24 hours

Authors can still release new versions via GitHub directly; new releases are auto-reviewed. If a release fails review, the dashboard surfaces the details. Pre-flight options:

- Run the [official eslint plugin](https://github.com/obsidianmd/eslint-plugin) locally
- Preview-scan any branch / tag / commit from the dashboard

## Capability disclosures (roadmap)

The "future" half of the post: plugins will declare what they access — **network, filesystem, clipboard, and other capabilities** — and users will see those disclosures *before installing*. Verified-author labels for developers in good standing after additional verification.

This is the install-time disclosure pattern the wider supply-chain-security cluster has been moving toward — see [[sandboxing-ai-agents]] for the same four-layer axis applied to AI coding agents, and [[whitelist-capability-config]] for the embedded-scripting variant. The structural problem is identical: a thing that can do anything is unsafe to install widely, so the ecosystem either gets sandboxed (filesystem/network/syscall layers) or capability-disclosed (the user opts in to specific powers). Obsidian's choice is disclosure — plugins still run with full process access, but users see what each one *says it touches*.

## Teams and private plugins

Existing teams' [deploy safety controls](https://help.obsidian.md/teams/deploy) get expanded with:

- Easier management of which community plugins are allowed for team members
- Distribution of **private plugins** to team members (closed-source supported here; the public directory is still open-source-only for new submissions)
- *Official* badge available to teams whose plugins meet the official integration bar

## Closed source

The new directory is **not accepting new closed-source plugins**. Existing closed-source plugins continue to be available "until further notice"; the team is considering how to adapt the automated review for them. This is a deliberate narrowing of trust: post-launch, anything new in the directory has source the scanner can read.

## What it doesn't do

The post is clear about scope:

- Obsidian Community is **not a store** — no built-in payment. Developers handle payment externally; the directory only labels (*free* / *optional payments* / *paid*).
- Currently only GitHub is supported as a source host. Other forges are explicitly on the *future-consider* list, not the launch list. (See [[forge]] / [[toolbox/forge|Nesbitt's forge]] for what the cross-forge surface looks like in the Go ecosystem.)
- Co-maintainer / org access still has the GitHub-only-owner limitation; multi-collaborator support is planned.

## Where it fits

This is a plugin-ecosystem hardening event in the same family as:

- [[supply-chain-security]] / [[tanstack-npm-supply-chain-postmortem]] / [[fsnotify-maintainer-dispute]] — the npm-and-friends side of the same pressure. Per-release scanning + signing/attestation are the same defensive moves Astral applies on the publisher side ([[open-source-security-astral]]).
- [[features-to-steal-from-npmx]] — Nesbitt's "what a modern registry frontend should expose" list. The Obsidian directory adds several of those primitives (sortable views, per-project status, author pages, paid labels).
- [[clippy-stricter-config]] — same instinct as Schwartz's lint-tightening post: the default tooling has to get stricter as the volume of generated code climbs.
- [[obsidian-ai-complete-guide]] — Huashu's blog runs on top of Obsidian's plugin ecosystem; this launch tightens the floor under that whole class of work.

For the wiki specifically, the load-bearing claim is that *coding-agent-generated plugins* are the volume problem the new pipeline is built for. That's the same observation [[ceo-ai-psychosis]] / [[ai-great-leap-forward]] / [[average-is-all-you-need]] / [[i-dont-want-your-prs]] all track from different angles — once the cost of producing a unit of work collapses, the gatekeeping system has to move from "review every submission" to "scan every release and selectively review the ones that matter."