Open and index any folder from system file manager via right-click: The "Transient Mode" Centralised Cache solution

Feature requests
1

Feature Request: Open any folder via right-click (Transient Mode Centralised Cache)

1. The Problem & The Unhandled Use Case

Currently, Obsidian is highly inflexible when it comes to viewing arbitrary folders on a system. The core assumption of the application is that every folder opened must be configured as a dedicated, self-contained “Vault”.

Because of this, if a user wants to right-click a random folder of Markdown files in Windows Explorer or macOS Finder and select “Open with Obsidian”, the system breaks. Obsidian either demands a pre-existing vault configuration or proceeds to write a local, hidden .obsidian folder to the directory.

This completely blocks the natural, ad-hoc use case: using Obsidian to quickly browse, search, and edit various folders of notes across a hard drive without cluttering them with configuration files or forcing a formal “Vault creation” process.

2. Why Existing Proposals Fall Short

While similar requests exist, the community has typically proposed workarounds that compromise Obsidian’s core strengths:

  • A “Dumb” Text Editor Fallback: This strips away indexing, graph views, and search, rendering Obsidian no better than Notepad or VS Code.
  • On-the-Fly Local Configs: Scripts that dynamically write and delete a temporary .obsidian folder on launch. This is messy and leaves abandoned junk files if the app or OS crashes.

Our proposed solution is fundamentally different. It does not ask Obsidian to run without an index or write messy temporary files. Instead, it simply shifts where that index and configuration are stored.

3. The Solution: The Hybrid Centralised Caching Model

We can achieve the best of both worlds by introducing a Transient Mode that coexists with traditional vaults.

  • Traditional Vaults (Unchanged): Users keep their portable, self-contained vaults with local .obsidian folders.
  • Transient Mode (The New Feature): When a user opens an arbitrary folder (via Explorer, CLI, etc.) that does not contain a local .obsidian folder:
    1. Obsidian opens the folder in a read/write Transient Mode.
    2. The app generates a unique hash based on the folder’s physical system path.
    3. Instead of writing a local .obsidian folder, Obsidian saves all workspace states, history, search indexes, and plugin configurations to a centralised, hidden system directory (e.g., %APPDATA%\Obsidian\transient_cache\<folder_hash>\).
    4. The user gets the full “Obsidian brain” (backlinks, search, themes) without altering a single byte of the target folder’s metadata.

The On-Ramp (Transition Banner)

If a user realizes they are using a transient folder frequently, Obsidian can display a discrete top banner:

:light_bulb: You are viewing this folder in Transient Mode. [Convert to Dedicated Vault]

Clicking the button would automatically copy the settings from the global cache folder and write a standard, local .obsidian folder to the directory.

4. Naming Ideas for This Centralised Cache

Because this background cache is essentially a “hidden, aggregate vault” that maps to multiple physical locations, it needs a name that makes sense to the user. Here are a few options:

  • The Shadow Vault: Implies it mirrors the physical folder’s content in a virtual, non-intrusive way.
  • The Portal / Portal View: Suggests the user is looking into a folder through a clean pane of glass, rather than unpacking their bags and settling down.
  • Transient Workspace: A clean, technical name that clearly communicates its temporary and isolated nature.
  • Omni-Cache / Universal Vault: Reflects a single, global pool of indexes that handles all ad-hoc folder requests.
2

Feature Request: Open any folder via right-click (Linked Mode — Centralised Cache) — Architecture & Business Model Compatible

Note: This post supersedes my earlier request, “Open and index any folder from system file manager via right-click: The ‘Transient Mode’ Centralised Cache solution”. That version is out of date — this one reflects a substantial rework (including the renamed “Linked Mode,” prior-art references, and a limitations section). I’m unable to delete or edit the old post, so please treat this thread as the current version and disregard that one.

Executive Summary

Obsidian currently forces every folder you open to become a registered, self-contained “Vault” — there’s no way to quickly browse a folder of Markdown files you don’t own or don’t want to commit to, without either registering it or writing a .obsidian folder into it. Several existing forum threads have chipped away at pieces of this (CLI/URI opening without pre-registration, moving workspace.json out of synced folders), but none combine into a single solution.

Linked Mode does: it opens any folder instantly with full indexing, search, and graph functionality, stores all of that state in a centralised system cache instead of the folder itself, and offers a one-click, zero-backend-cost path to convert into a full Dedicated Vault (with Sync/Publish support) the moment the user actually wants that. It’s designed to slot into the existing cross-platform architecture and business model with no compromises to either — details, prior art, and known tradeoffs are laid out below.

Table of Contents

  1. The Problem & The Unhandled Use Case
  2. Relationship to Existing Requests
  3. The Solution: Linked Mode (Centralised Caching Model)
  4. Native Compatibility with First-Party Services (Sync & Publish)
  5. Universal Cross-Platform Architecture
  6. Known Limitations & Design Tradeoffs
  7. Why Existing Workarounds Fall Short
  8. On the Recent-Folders Question

1. The Problem & The Unhandled Use Case

Currently, Obsidian is highly inflexible when it comes to viewing arbitrary folders on a system. The core assumption of the application is that every folder opened must be configured as a dedicated, self-contained “Vault.”

Because of this, if a user wants to right-click a random folder of Markdown files in Windows Explorer, macOS Finder, or a mobile file picker and select “Open with Obsidian” (feature TBC), the system breaks. Obsidian either demands the folder be pre-registered as a vault, or writes a local, hidden .obsidian folder into the directory the moment it’s opened.

This blocks a natural use case: using Obsidian to quickly browse, search, and edit various folders of notes across a device — including folders you don’t fully control, like a shared drive, a USB stick, or someone else’s project directory — without cluttering them with configuration files or forcing a formal “vault creation” process.

2. Relationship to Existing Requests

This isn’t an isolated ask — there’s active, moderator-acknowledged interest in this general area, and it’s worth being upfront about how this proposal relates to it rather than have it pointed out in the replies:

  • “Open folder as an Obsidian vault from terminal / command line / CLI” (active, tagged valuable) — same underlying frustration, but the proposed fix is to auto-generate .obsidian in the target folder on open. That solves the registration friction problem but not the “don’t touch my folder” problem — it still writes into a directory you may not own or want modified.
  • “Open a folder as a (new) Obsidian vault using its filepath via the URI” — same goal via obsidian:// URIs, same limitation.
  • “Store .obsidian folder outside the vault folder” — different trigger (workspace.json churn polluting Google Drive/Dropbox sync activity between collaborators), but structurally the same solution as this proposal: move vault-specific state out of the folder and into a system location.
  • “Obsidian outside of a vault” — an earlier, cruder version of this idea (fallback config only, no indexing or search).

Linked Mode is proposed as the architecture that resolves all four at once: it removes registration friction (open any folder immediately), it never writes into the target folder (solving the sync-pollution complaint as a side effect, at no extra engineering cost), and it keeps full indexing/search/graph functionality that the “fallback config” idea gave up on.

3. The Solution: Linked Mode (Centralised Caching Model)

We can achieve the best of both worlds by introducing Linked Mode, which coexists with traditional vaults:

  • Traditional Vaults (Unchanged): Users keep their portable, self-contained vaults with local .obsidian folders. Sync and Publish function exactly as they do now.
  • Linked Mode (The New Feature): When a user opens an arbitrary folder that does not contain a local .obsidian folder, Obsidian opens it in Linked Mode.
    • Obsidian computes a hash from the folder’s resolved, normalised path — symlinks/junctions resolved to their real target, trailing separators stripped, case-folded on Windows and macOS — so that the same physical folder always maps to the same cache entry regardless of how it was opened.
    • Instead of writing a local .obsidian folder, Obsidian saves all workspace state, history, search indexes, and plugin configuration to a centralised, hidden system directory, keyed by that hash.
    • The user gets the full “Obsidian brain” (backlinks, search, themes) without altering a single byte of the target folder’s contents or metadata.

4. Native Compatibility with First-Party Services (Sync & Publish)

A critical priority for this feature is ensuring it does not break or bypass Obsidian Sync or Obsidian Publish. Because Linked Mode separates configuration from data, it’s designed from the ground up as a local-only experience that maintains seamless compatibility with first-party services.

  • The Conversion Prompt: If a user in a Linked Mode workspace attempts to activate Obsidian Sync or Publish via the core plugins, they receive a simple prompt: “To use Obsidian Sync or Publish, this folder must be converted into a Dedicated Vault.”
  • The On-Ramp (Transition Banner): Obsidian can also display a discrete top banner at all times: “You are viewing this folder in Linked Mode. (Convert to Dedicated Vault)”
  • Clicking this button copies the settings from the global cache and writes a standard, local .obsidian folder into the directory. This requires zero backend changes to the Sync/Publish services themselves — it’s a client-side conversion that produces exactly the vault structure Sync/Publish already expect.

5. Universal Cross-Platform Architecture

This solution maps cleanly onto Obsidian’s unified Electron/Capacitor codebase and the standard application data directories it already uses on every platform:

  • Windows: %APPDATA%\Obsidian\linked_cache\<folder_hash>\
  • macOS: ~/Library/Application Support/obsidian/linked_cache/<folder_hash>/
  • Linux: ~/.config/obsidian/linked_cache/<folder_hash>/
  • iOS / Android: Obsidian’s native sandboxed app storage — see limitations below; mobile needs its own treatment rather than a direct copy of the desktop model.

Whether triggered via right-click on desktop or the “Open Folder” picker on mobile, the app respects the host OS file system without littering it.

One UX question to resolve alongside this: do Linked Mode folders appear anywhere in Obsidian’s UI after being opened — the vault switcher, a “Recent folders” list, or nowhere at all? Worth specifying up front rather than leaving it implicit. (My own take on this is in section 8.)

6. Known Limitations & Design Tradeoffs

Being upfront about these is better than having them surface as objections in the replies:

  • Moving or renaming the folder breaks the link. Because the cache key is derived from the resolved path, moving the folder (or, on Windows, a drive-letter change for removable media) will not carry the cache forward automatically. This is an accepted tradeoff of the local-only design, not a solved problem — Obsidian should treat it as “fresh Linked Mode session” rather than fail silently.
  • Mobile is a separate problem, not a smaller version of desktop. iOS/Android don’t expose stable filesystem paths for externally-picked folders — access is mediated through security-scoped bookmarks (iOS) or SAF URIs (Android), which aren’t guaranteed to remain stable across re-picks. Linked Mode should be scoped as desktop-first, with mobile support explicitly deferred pending its own design rather than assumed to work identically.
  • Community plugins that write their own data files (not just settings) under .obsidian/plugins/<name>/ need either transparent path redirection or an explicit “not supported in Linked Mode” flag surfaced to the user — this isn’t zero-effort the way the Sync/Publish conversion is.
  • Cache garbage collection. Without cleanup, deleted, moved, or permanently unreachable source folders (dead USB stick, removed network share) leave orphaned index data indefinitely in the app data directory. A simple policy — prompt to purge after N days unreachable — avoids Obsidian quietly accumulating stale data on the user’s system.

7. Why Existing Workarounds Fall Short

Separate from the specific threads linked above, the general categories of workaround the community has reached for also compromise Obsidian’s core strengths:

  • A “Dumb” Text Editor Fallback: Strips away indexing, graph views, and search — rendering Obsidian no better than Notepad.
  • On-the-Fly Local Configs: Scripts that dynamically write and delete a temporary .obsidian folder on launch. Messy, and leaves abandoned junk files if the app or OS crashes mid-session.

Linked Mode shifts where the index is stored rather than removing it — preserving all of Obsidian’s power, keeping the file system pristine, and supporting the company’s core ecosystem (Sync, Publish) with no changes required on the backend side.

8. On the Recent-Folders Question

I’ll leave the question in section 5 open for discussion, but my own leaning: the entire point of Linked Mode is to be gung-ho and low-commitment — open a folder, poke around, close it, done. Surfacing it in a “Recent Folders” list (or the vault switcher) reintroduces exactly the kind of persistent tracking and registration overhead this feature exists to avoid. I’d default to not listing Linked Mode folders anywhere in Obsidian’s own UI, and let the host OS’s native “recent locations” (Explorer, Finder, etc.) handle rediscovery if a user wants to reopen one — that’s already Obsidian-independent and free.

3

Hi, please don’t post revisions of feature requests as new feature requests. I’ve merged this into the original thread for now. If you like, you can edit the original post, or you can post revisions as new comments.

Also, please follow the feature request template (the text that appears in the writing field when you start a new request). I’m leaving this here for now, but it may get moved out of Feature requests because it doesn’t follow the template.

4

Thanks for that.

I did try to edit the original post although the forum UI wouldn’t let me edit it nor delete it.
Best wishes