Obsidian: The Future of Plugins

May 2026 launch post from the 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 — 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 account + GitHub OAuth):

Sign in to community.obsidian.md
Connect GitHub, pick a repo
Complete dashboard steps (categories, screenshots, pricing label)
Submit — automated review runs immediately, typical result in minutes
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 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 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 / 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."