I wasn't sure of the best place to create this issue given it could be intended behaviour. I settled on having the skill be aware so that the agent using it could make an informed decision.
Caveat, feedback below is from a conversation with Claude where i noticed a subprocess hanging:
Diagnosed.
Root cause: obsidian help is spawning a second Obsidian Electron instance (PIDs 48918, 48919, plus their renderer/network helpers) rather than printing static help and exiting. The CLI binary itself does write the help text — head -80 received it — but the parent zsh stays blocked because the Electron child-process tree never exits.
Other commands you've been running (obsidian read, obsidian create, obsidian property:set, obsidian templater:create-from-template) return fast because they talk to the already-running Obsidian app over IPC and exit when the IPC call returns. help doesn't need the app, so it bypasses IPC and tries to bootstrap its own Electron context — and that context never gets a clean shutdown signal, especially when stdout is closed early by a pipe like | head.
Evidence in ps: PID 48843 is the zsh wrapping obsidian help 2>&1 | head -80, still alive. Right beneath it, PIDs 48918/48919/etc. are a second set of Obsidian Helper (GPU) / Helper (Network) processes — distinct from your main app's helpers (44758/44759). The pipe SIGPIPE'd the CLI's stdout, but the Electron helper tree didn't notice and held the parent alive.
Workarounds:
Don't pipe obsidian help — let it write to terminal or > file, then it tends to exit (still slow but finishes).
Wrap with timeout: timeout 5 obsidian help 2>&1 | head -80.
Best: skip obsidian help entirely and keep a local cheat-sheet, since the help text is static.
I wasn't sure of the best place to create this issue given it could be intended behaviour. I settled on having the skill be aware so that the agent using it could make an informed decision.
Caveat, feedback below is from a conversation with Claude where i noticed a subprocess hanging: