Steps to reproduce
- Open any registered vault in desktop Obsidian.
-
- Run:
-
bash - /Applications/Obsidian.app/Contents/MacOS/Obsidian version ‘vault=does-not-exist’
- /Applications/Obsidian.app/Contents/MacOS/Obsidian vault ‘vault=does-not-exist’ ‘info=path’
- /Applications/Obsidian.app/Contents/MacOS/Obsidian read ‘vault=does-not-exist’ ‘path=some-note.md’
-
-
- Observe the output.
-
Did you follow the troubleshooting guide? [Y/N]
N. I searched the forum for duplicates first. I have not yet gone through the full troubleshooting flow because this reproduces when invoking the official CLI binary directly and appears to happen at vault selection before any plugin/theme-specific behavior.
Expected result
If vault= does not match any registered vault, the CLI should fail explicitly, for example with a non-zero exit code and Vault not found.
Actual result
The commands succeed against the currently open vault instead:
versionreturns the app version-
vault info=pathreturns the currently open vault path-
readreturns note content from the currently open vault
- That makes shell scripts and automation think the target vault was resolved successfully even though the selector does not exist.
-
Environment
SYSTEM INFO:
Obsidian version: v1.12.4
Installer version: v1.12.4
Operating system: macOS 15.7.3 (arm64)
No custom helper is needed to reproduce this. The commands above call the official Obsidian binary directly.
Additional information
I found related but different threads about CLI and URI behavior, including:
- Command Line Interface to open folders (and files) in Obsidian from the terminal
-
- URI callback not working correctly (trying to open from CLI on linux)
- I could not find an existing report for this exact invalid-selector fallback behavior.
This seems especially risky for automation and CLI usage because an invalid selector fails open instead of fail closed.