Request
I want to be able to use my terminal (and the Obsidian CLI, I presume) to open up a folder in my filesystem as a defacto Obsidian vault.
- It should not be necessary to have registered the folder as an Obsidian vault previously in order to open it
- Opening a vault this way should not register the vault to Obsidian, except if a flag is passed explicitly asking for it
- If the folder has no
.obsidianmetadata folder, one should be generated for it - If a window is already open to that folder, the window is focused instead of creating a new window
Use Cases
I personally have two different use cases where this feature would be useful:
-
I’m working on several plugins at the moment, and each has their own independent test vault, all of them with identical names. I’d like to be able to open the vault via an npm command or something similar without Obsidian needing to know beforehand of this vault’s existence. My workaround is registering each vault first and giving them unique names in order to open them, but it’s an inconvenient series os steps which pollutes my vault list.
-
I’m working on an tool which generates Obsidian vaults using external data converted to markdown files, and leverages Obsidian’s tools and extensions to navigate and visualize the data. The pain point here is that I cannot make my tool open the generated vault after it’s done, I need to first manually register the vault with Obsidian using the UI.
Proposed solution
Open a vault by passing a path to the Obsidian CLI:
obsidian vault C:\Users\MyUser\Desktop\Notesto open a folder using an absolute pathobsidian vault .to open the currently navigated folderobsidian vault . –-registerto open the currently navigated folder, and add the vault to the user’s vault list
Current workaround
There is currently no workaround to do this entirely within the terminal. The best you can do is add the folder you want as a registered vault using the Obsidian UI, and then use the CLI to open it by name (not by path)
Related feature requests
There are some feature requests similar to this one, but it was determined that those requests changed scope and were eventually satisfied by the latest 1.12 updates, whereas the request made here is not satisfied by the 1.12 updates: