lock

Invoke the lock_vault MCP tool.

Argument parsing from $ARGUMENTS

• bare vault name → vault=<name>, persist defaults to false
• <name> --persist or "permanently" / "persist" / "de manière permanente" / "qui survit au restart" → persist=true
• vault=X persist=true — explicit form

Always

• Verify the named vault is in the active set (the tool itself does this and refuses otherwise — surface the error clearly to the user, including the list of known vaults).
• After a successful lock, confirm to the user: which vault, whether the lock is volatile or persisted, and where the .env hint was written if persisted. Read persisted from the result, do not infer it from persist: true — it means "will survive a restart", so it is false when the router config could not be written even though the .env line was. In that case the result also carries hintWritten: true and a message saying the lock does NOT survive; relay that rather than reporting success.
• If the user phrased it persistently ("permanently", "de manière permanente", "à chaque démarrage") but didn't explicitly say "persist", default persist=true — that's clearly their intent.
• If the user phrased it temporarily ("just for now", "juste pour cette session", "pour l'instant"), default persist=false.

Push back if

• The vault name is missing or ambiguous → ask for the explicit name.
• The user is already locked to a different vault → tell them, ask if they want to switch (which means re-running lock with the new name) or unlock first.

Homedir refusal caveat (persist mode only)

If the user asks for a persistent lock from their home directory (e.g., they launched Claude Code from ~ rather than a project folder), the tool refuses with an explicit error and the in-memory lock still applies for the session. Surface the message verbatim — it tells them how to fix it (run from a real project directory, or set OBSIDIAN_ROUTER_LOCKED=<vault> in their shell profile / PowerShell $PROFILE). Do not retry the persist call from the same cwd.