A non-standard, symlink-based Obsidian architecture on macOS

Help
1

Hi everyone,

I’m experimenting with a non-standard, symlink-based Obsidian architecture on macOS, and I’d like to contribute a technical deep-dive — not workarounds, but what’s actually happening under the hood.

Goal: One “Brain”, Many Vaults

I want:

  • Shared tools: plugins, hotkeys, snippets, templates, UI

  • Isolated knowledge: each vault = separate graph, tags, backlinks, project context

This is not about tags or workspaces — it’s about filesystem structure + Obsidian’s runtime behavior.

Architecture (macOS symlinks)

Vault-Brain/          ← “global config”
├── .obsidian/
│   ├── community-plugins.json → symlink
│   ├── plugins/ → symlink
│   ├── hotkeys.json → symlink
│   └── snippets/ → symlink

Vault-Project-A/
└── .obsidian/ → symlink to Vault-Brain/.obsidian

Vault-Project-B/
└── .obsidian/ → symlink to Vault-Brain/.obsidian

:white_check_mark: Works for:

  • UI, hotkeys, snippets, templates — all shared perfectly

  • Each vault keeps its own graph, tags, backlinks — clean separation

:cross_mark: Fails for:

  • Community plugins do NOT activate in cloned vaults

  • Settings → Community plugins shows them as “disabled” — even though files are present

Key Technical Observation

This is not a symlink issue — it’s an Obsidian runtime architecture decision.

Plugin enablement state is not stored solely in .obsidian/ — it’s stored outside the vault, likely in:

~/Library/Application Support/Obsidian/

This folder likely holds:

  • Vault identity (UUID or path hash)

  • Plugin enable/disable state per vault

  • Plugin ↔ vault binding

That’s why:

  • Config files sync fine via symlinks

  • But plugins don’t “clone” — because Obsidian binds plugin state to a specific vault ID, not to the config files

The Real Question

Is it technically possible to:

  • Run multiple vaults

  • Share a single plugin “brain”

  • Without manually enabling plugins per vault?

Has anyone on macOS:

  • Used this model long-term?

  • Encountered corruption, instability, or hard limits?

  • Found a way to override or spoof the vault ID binding?

This feels like a fundamental architectural choice — not a bug, not a macOS limitation.

I’m looking for real-world experience and technical confirmation, not tag-based or workspace-based workarounds.

Thanks for any deep insight — especially from those who’ve tried this at scale.
[#Ai-cowork]

2 
Vault-Brain/          ← “global config”
├── .obsidian/
│   ├── community-plugins.json → symlink
│   ├── plugins/ → symlink
│   ├── hotkeys.json → symlink
│   ├── snippets/ → symlink
│   ├── templates/ → symlink   ← ✅ SHARED!
│   ├── styles/ → symlink     ← ✅ CSS THEMES — WORK PERFECTLY!
│   └── templates.json → symlink
3

Moderators note: This comment was originally posted in Global Settings / Same settings, themes, and plugins across multiple vaults in reply to another comment there. The connection between them lost when this post was moved.

Hi @mikeyo,

Thank you for sharing your junction-based setup — this is exactly the kind of real-world confirmation this thread needs.

I’m running a similar experiment on macOS with symlinks and hit a specific wall: UI, hotkeys, snippets, and templates share perfectly — but community plugins do not activate in cloned vaults, even when plugins/ and community-plugins.json are present and correctly linked.

My hypothesis is that Obsidian stores plugin enablement state outside .obsidian/ — likely in ~/Library/Application Support/Obsidian/ (or the Windows equivalent) — bound to a vault-specific identity, not to the config files themselves.

Before I conclude this is a macOS-specific limitation vs. a junction vs. symlink difference, I’d like to verify your setup:

  1. After setting up the junction, did your community plugins appear as enabled in [Settings → Community plugins] in the second vault — without manually toggling them?
  2. Did the plugins actually run (e.g. Dataview rendered queries, Templater executed templates) — or were they listed but inactive?
  3. Have you tested this after a full Obsidian restart — not just a vault switch?

If junctions on Windows bypass the vault-identity binding that symlinks on macOS do not, that would be a significant architectural finding — and worth documenting for the community.

4

I moved your posts out of the comments of Global Settings / Same settings, themes, and plugins across multiple vaults because it sounds like you’re looking for answers to something you’re working on, more than contributing to the discussion there.

This is why you’re seeing plugins not enabled:

By default, Obsidian runs in Restricted Mode to prevent third-party code execution. (Plugin security - Obsidian Help)

This way you can download a vault from the Internet and open it without it running the code in whatever plugins might be in it.

Are you creating a large number of vaults? Or perhaps creating temporary vaults? I’m curious why the need to turn off Restricted Mode is an issue.

5

I’ve tried to use symlinks too on windows and something didn’t work, probably the plugins, like you said. Then I tried to use junctions and it did the trick. Have you tried junctions? I’m very curious whether it worked for you. The plugins do run, including Dataview, though I don’t use it much.
If you pick .obsidian folder of the Vault 1 as a source for junctions, any change you make in terms of settings or plugins will be exactly the same in all other linked vaults. So if you open Vault 1, toggle all the plugins, and then start Vault 2, all the plugins will be enabled in Vault 2. If you open Vault 1 and disable all the plugins and then start Vault 2, all the plugins will be disabled in Vault 2. And it works the other way around. Any change you make to the plugins or settings in any vault is actually just a change to the .obsidian folder in Vault 1. The only downside is that open tabs are stored in the .obsidian folder too, so if you switch between vaults, it can’t remember the open tabs. But it’s fine for me.