Spec: Obsidian CLI escalation routing
Goal
Teach the agent to retry obsidian commands with elevated access when the CLI can reach the binary but cannot reach the running Obsidian app or vault context.
Problem
The current workflow treats an obsidian failure as a hard stop too early. In practice, the failure can come from missing app context rather than a real permission denial. That leads to avoidable fallback to direct filesystem edits.
Proposed behavior
- Run
obsidian normally first.
- If the command fails because the app is unavailable, the vault is unreachable, or the CLI cannot resolve the focused vault, rerun the same command with
sandbox_permissions=require_escalated.
- If the elevated retry also fails, fall back to direct filesystem access.
Scope
- Update repo-level workflow docs in
AGENTS.md and GEMINI.md.
- Update shared memory docs in
~/.agents/AGENTS.md and ~/.agents/GEMINI.md.
- Do not modify the Obsidian CLI skill file.
Non-goals
- No changes to the
obsidian binary.
- No changes to the vault content format.
- No changes to snippet migration logic.
Success criteria
- The escalation rule is documented in both repo and shared memory files.
- The rule is specific enough that future sessions can apply it without re-deriving the behavior.
- The Obsidian skill file remains untouched.