Obsidian's own documentation says it cannot reliably restrict plugins to specific permissions, so community plugins inherit Obsidian's access: they can read files on your computer, connect to the internet and install additional programs. Restricted Mode, on by default, blocks third-party plugin code until you turn community plugins on.
What Obsidian states
The Obsidian help page on plugin security says three things worth repeating.
- By default Obsidian runs in Restricted Mode to prevent third-party code execution. You should only turn it off if you trust the authors of the plugins you install.
- Because of technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels, so plugins inherit Obsidian's access levels.
- If you work with sensitive data and want a community plugin, the team recommends an independent security audit of that plugin first.
Installed plugins stay in your vault when you switch Restricted Mode back on, but Obsidian ignores them.
How the review process works
Obsidian says all community plugins must follow its developer policies, and that it automatically scans every plugin version for security vulnerabilities, code quality issues and malware. The results appear as a safety scorecard on each plugin's page in the directory. Manual reviews continue for popular, featured and flagged plugins.
You can flag a plugin you suspect is malicious from its directory page, or report it to Obsidian support. For a vulnerability, the page points you to the plugin author's security or readme file, and for critical flaws also to Obsidian support.
Where this sits among plugin models
| Model | What stops a plugin doing too much |
|---|---|
| Per-plugin permission prompts | The platform asks, and enforces what you grant |
| Isolated hosted runtime | The platform restricts network and data access |
| Inherited access plus review | Scanning and policy, but the plugin runs with the app's access |
Obsidian is in the third group, which it states openly. That honesty is useful, because it tells you exactly where your own judgment has to do the work. The post sandbox, permissions or review: three plugin protections compared compares the groups.
A decision guide
Notes with no sensitive content. A scan-reviewed plugin with a clear purpose and an active author is a reasonable risk for many people. Check the scorecard and recent updates.
Vaults with client, legal, health or credential content. Treat each plugin as software with file access. Options include a separate vault with no plugins for sensitive material, a separate vault for experiments, or a code review of the plugin before use.
Teams. Decide whether staff may enable community plugins at all, and keep a list of what is approved. An unmanaged vault on a laptop that also holds source code is a data path you may not have mapped.
Practical habits
- Keep Restricted Mode on in vaults that do not need plugins.
- Install fewer plugins, and remove ones you no longer use.
- Check when a plugin last updated and who maintains it.
- Be cautious after a plugin changes hands.
- Do not store passwords or API keys in plain notes, plugin or no plugin.
The same inherited-access reasoning applies to editors and other desktop tools. What can a VS Code extension access walks through the developer version.
Safeguard works at the software supply chain level for code you build, with asset discovery and dependency scanning. It does not review note-taking plugins, but the habit of treating plugins as code with access is the same one we recommend for packages.
Quick check
Does Restricted Mode delete my plugins?
No. According to Obsidian, installed plugins remain in your vault but are ignored while Restricted Mode is on.
Can I limit a plugin to one folder?
Obsidian says it cannot reliably restrict plugins to specific permissions or access levels. Use separate vaults to separate sensitive and non-sensitive material.
Sources
Last reviewed: 19 October 2026.
