Issue
Each obsidian move CLI command spawns a new full Electron/Obsidian app instance instead of communicating with the already-running Obsidian process via IPC. Running ~40 move commands resulted in ~90
Obsidian processes (each Electron instance spawns GPU helper, network helper, renderer sub-processes) and a flooded Dock.
Steps to Reproduce
1. Open Obsidian normally (1 instance running)
2. Run multiple CLI move commands in quick succession:
obsidian vault=Study move file=“Note A” to=“Subfolder/Note A”
obsidian vault=Study move file=“Note B” to=“Subfolder/Note B”
obsidian vault=Study move file=“Note C” to=“Subfolder/Note C”
# … repeat
3. Observe the Dock filling with duplicate Obsidian icons
4. pgrep -f Obsidian | wc -l shows 90+ processes
Expected Behavior
CLI commands should communicate with the existing Obsidian instance (e.g., via IPC socket, URL scheme, or local HTTP server). A single Obsidian process should handle all commands. Other CLI tools that
wrap Electron apps (VS Code’s code CLI, for example) do this correctly.
Actual Behavior
-
Each CLI invocation launches a new Electron app process
-
Each new process spawns 2-3 helper sub-processes (GPU, network, renderer)
-
Commands hang indefinitely — produce no stdout/stderr, never exit
-
The move operation itself silently fails — files are not moved on disk
-
Processes resist pkill and killall — required kill -9 or AppleScript quit
-
The only way to actually move files was to bypass the CLI entirely and use mv on the filesystem
Additional Issue: move destination path handling
When the move command does produce output, it misinterprets the to= parameter:
obsidian vault=Study move file=“Note” to=“Folder/Subfolder/Note”
# Error: ENOENT: rename ‘…Note.md’ → ‘…/Note/Note.md’
It treats the last path segment as a folder name rather than the destination filename, then tries to place the original filename inside it.
