[Bug]: obsidian CLI occasionally opens a second Obsidian window/vault-chooser when invoked from Claudian's Bash tool

Summary

When Claude (running inside Claudian's Bash tool) invokes the built-in obsidian CLI to move/rename vault files (as instructed by Claudian's own system prompt guidance for link-aware file operations), it occasionally spawns a second, separate Obsidian window (the vault chooser/creation screen) instead of talking to the already-open vault/window that Claudian itself is running in. This happens intermittently, not on every invocation, and the user has to manually close the stray window (it doesn't affect the real vault).

Environment

• Obsidian: 1.13.7 (installer 1.13.7)
• Claudian: 2.2.7
• OS: macOS (Darwin 25.6.0)
• Single vault registered and already open (confirmed via obsidian vaults verbose → exactly one entry, name matches folder exactly, "open": true in obsidian.json)
• obsidian CLI correctly resolves to /usr/local/bin/obsidian → symlink to /Applications/Obsidian.app/Contents/MacOS/obsidian-cli

Steps to reproduce (best known so far)

1. Have Obsidian running with a vault open, Claudian active in that vault.
2. Ask Claude (inside Claudian) to move/rename a vault file — Claudian's system prompt tells the agent to use obsidian vault="<name>" move path="..." to="..." for link-aware moves.
3. Run several such CLI calls in a session (e.g. during an inbox-processing workflow with 2+ file moves).
4. Occasionally (not every time — no reliable repro yet), a brand-new, separate Obsidian window appears showing the "Select or create a vault" chooser, instead of the command just executing silently against the already-open vault/window.

Root cause hypothesis

This looks like the same underlying class of bug already root-caused by Obsidian staff for OpenAI Codex, see: https://forum.obsidian.md/t/openai-codex-sandboxed-cli-invocation-can-launch-a-second-obsidian-process-that-crashes-even-when-the-main-app-is-already-running/113099

Summary from that thread: a sandboxed coding-agent environment invoking the obsidian CLI can fail to reach the running app through its local IPC socket (~/.obsidian-cli.sock). When the CLI can't reach the existing process in time, it falls back to launching Obsidian again — in the Codex case this crashed a short-lived second process; in our case it appears to surface as a full vault-chooser window instead (possibly because Claudian's embedding differs slightly from Codex's, or because the fallback path differs by Obsidian version — 1.13.7 here vs whatever version that report was against).

A possibly-contributing, machine-specific factor I found

On this machine, $PATH (as seen by Bash tool calls) contains both:

• /usr/local/bin (has the correct CLI symlink obsidian → obsidian-cli)
• /Applications/Obsidian.app/Contents/MacOS (contains the actual GUI Electron binary Obsidian)

Because macOS's default filesystem (APFS) is case-insensitive, Obsidian and obsidian are the same file from a lookup perspective — so /Applications/Obsidian.app/Contents/MacOS also effectively provides a same-named obsidian command, which happens to be the raw GUI app binary, not the CLI client. Right now /usr/local/bin wins because it's earlier in $PATH, so which obsidian correctly resolves to the CLI. But if Claudian's own process-spawning code ever builds/inherits a different or filtered PATH for the agent's shell (rather than the user's actual interactive shell PATH), it's plausible that obsidian could occasionally resolve to the raw GUI binary instead of the CLI — directly launching a fresh Electron instance rather than round-tripping through the socket, which would manifest exactly as "a whole new Obsidian window with the vault chooser."

Worth checking: does Claudian's Bash tool build its own PATH for spawned shells, or always inherit the user's login-shell PATH verbatim? If it constructs/filters it, that would be a good place to look for why this is intermittent (e.g. a race between the agent's shell PATH resolution and where /usr/local/bin sits vs /Applications/Obsidian.app/Contents/MacOS).

Suggested fixes / mitigations for Claudian

• When invoking the obsidian CLI from the agent's Bash tool, resolve and use an absolute path (/usr/local/bin/obsidian or the real symlink target) rather than relying on $PATH lookup, to eliminate any ambiguity with /Applications/Obsidian.app/Contents/MacOS being on PATH.
• Consider a short retry-with-backoff around the CLI's socket handshake before falling back to any kind of relaunch, since the underlying issue (per the Codex thread) is a flaky IPC connection from sandboxed processes, not a permanent failure.

Happy to provide more repro details/logs if useful — this has been intermittent so I don't have a 100% reliable repro script yet.