The Future of Obsidian Plugins

Plugin security model & risks

• Many are uneasy that Obsidian plugins currently run with full filesystem and network access, with no sandboxing; this is confirmed in the docs.
• Even without network access, full file access allows destructive or indirect attacks (e.g., modifying crontab or shell rc files).
• Some worry the new system doesn’t change this core “click here for RCE” model yet, so structural risk remains.

Automated scanning, AI, and review

• New community site and automated review are widely seen as a major scaling improvement; manual review had become a bottleneck.
• Automated checks use a custom eslint plugin plus dependency/malware scanning; every release is scanned, and rescans are planned as rules improve.
• Some see AI as a promising additional layer for catching malicious or user-hostile behavior; others argue AI is too fuzzy and non-reproducible for a security boundary.
• There is concern that a public linter/ruleset can be used by attackers to iteratively bypass checks, so hidden/extra checks are suggested.

Permissions, sandboxing, and desired controls

• Strong sentiment that a proper sandbox and explicit permissions (filesystem scope, network, external binaries) are the “real” fix.
• Obsidian’s new “disclosures” are described as a first step toward permissions, but currently rely partly on self-report and do not yet enforce sandboxing.
• Several note that permissions alone can’t prevent abuse of allowed capabilities (e.g., generic “network” permission used for exfiltration).

Ecosystem, developer experience, and plugin availability

• Developers welcome an easier submission pipeline and tooling (eslint rules, scorecards); some quickly improved their scores.
• Concerns exist about false positives/negatives, CVE noise, and user confusion over scorecards; filters by “strictness” are requested and apparently planned.
• Some fear good plugins could be delisted too aggressively (e.g., on a bad update) instead of defaulting back to the last safe version.

Trust, openness, and lock‑in

• A sizable group wants Obsidian itself to be open source for long-term trust, workflow stability, and verifiability.
• Others argue that plain Markdown storage and a stable, offline-capable client keep lock‑in relatively low, though plugin-specific formats remain sticky.
• Debate continues over whether a “trusted vendor” proprietary model is acceptable versus insisting on FOSS.

Collaboration, UX, and misc

• Several users struggle to replace Notion for team use; Obsidian is seen as strong for personal/agent workflows but weaker on permissions and onboarding for non-technical teammates.
• Some recommend real-time collaboration plugins (e.g., Relay, Peerdraft) and self-hosted sync tools.
• Dark-mode-only web content is criticized for accessibility (astigmatism, halation); light mode for the site is said to be planned.
• Multiple users list favorite plugins and advise adding them slowly, one by one, to keep complexity and risk manageable.