fix(capabilities): give open_path a scope so it can actually run

[PathGao]

Closes #399.

The defect

capabilities/default.json lists opener:allow-open-path, which grants the command. Scope is resolved separately, and there it fails:

Permission	commands	scope
allow-open-path	["open_path"]	null
allow-default-urls	[]	[mailto:*, tel:*, http://*, https://*]

A permission with no commands lands in the plugin's global scope, applying to every opener command — including open_path. And in tauri-plugin-opener 2.5.3:

fn matches_path_program(&self, a: Option<&str>) -> bool {
    match self {
        Self::Url { .. } => false,        // every entry we have is a Url
        Self::Path { app, .. } => app.matches(a),
    }
}

is_path_allowed = fs_scope.is_allowed(path) && allowed.any(matches_path_program) — the fs allow-list is empty, so the first conjunct is false; every scope entry is a Url, so the second is too. open_path returns ForbiddenPath on every platform in every window.

What it actually breaks today

One call site: the "Open exported HTML file now?" prompt after an HTML export. PDF export never offers it, and there is no auto-open anywhere — this is an opt-in yes/no dialog whose Yes button has never worked.

It is not silent: the call site catches the rejection and shows toast.openExportedFileFailed. So it has read as an ordinary failure rather than a missing capability, which is probably why it went unreported.

Why **

It matches the width the app already has, rather than adding to it:

• assetProtocol.scope is already ["**"] — the webview can read any file through asset://.
• read_file_content, save_file_content, copy_file, delete_file all take arbitrary paths from the frontend with no scope check.

So unrestricted read and write are already the status quo. The genuine increment is different in kind: open_path hands a path to the OS default handler, and for an executable that means launching it.

That increment belongs to the call site, not to the ACL. The two call sites differ:

Call site	Path comes from	Untrusted?
askToOpenExportedFile	a path the app just wrote, chosen by the user in a save dialog	no
relative link resolution (not yet shipped)	a link inside the open document	yes

Narrowing the ACL would block the first — which has no untrusted input at all — while the second is better answered where the path is produced. A follow-up PR adds that second call site; the question of what a document should be allowed to ask the OS to open belongs in its review, and I'll raise it there.

If you would rather have a narrower scope anyway, say so and I'll write it. Note it cannot be a static list: the export destination is wherever the user's save dialog pointed, so it needs the plugin's runtime scope API rather than a capabilities entry.

Verification

cargo build regenerates gen/schemas/capabilities.json, which now carries:

{ "identifier": "opener:allow-open-path", "allow": [{ "path": "**" }] }

Build clean. No behaviour change beyond the one command becoming callable — no test asserts the old rejection, and nothing else in the tree calls open_path.

🤖 Generated with Claude Code