allowed-tools: Bash(openspec:*) - narrower pattern for generated skills/commands?

[fraction01]

After updating to 1.6.0, I asked the Claude Code to review the changes and got this feedback about the allowed-tools: Bash(openspec:*) addition:

The wildcard covers more than in-project spec management. openspec store remove <id> --yes deletes a folder on disk (registered stores can point anywhere on the machine, not just this repo) — the command does have its own --yes confirmation gate, but that flag is just part of the same pre-approved command line, so nothing stops it running unconfirmed. openspec config set/reset has no confirmation at all, though its blast radius is limited to OpenSpec's own preferences file (profile/delivery/workflows/telemetry), not system-wide config. openspec archive/update rewrite files in the current repo — which is exactly what produced the diff batch you're looking at.

[...]

So: safe from the specific injection CVE (CVE-2025-66032), but broader than "just openspec status/list" — it trades a prompt on every openspec call (including destructive ones like store remove or config set) for convenience.

Is this a real risk in practice, or is the blanket wildcard fine as-is? If it is worth tightening, would narrowing the pattern to only the subcommands the generated skills/commands actually call make sense — something like:

allowed-tools: Bash(openspec status:*), Bash(openspec list:*), Bash(openspec show:*), Bash(openspec validate:*), Bash(openspec instructions:*), Bash(openspec new change:*), Bash(openspec schemas:*), Bash(openspec doctor:*), Bash(openspec context:*), Bash(openspec store list:*)

This still pre-approves everything used today, while leaving the destructive subcommands (store remove, config set/reset, archive, update) behind the normal permission prompt.

[clay-good]

Hey @fraction01, thanks for the question.

Worth noting allowed-tools only pre-approves, it never restricts, so the wildcard trades prompts for convenience but doesn't grant anything your permission settings wouldn't. The proposed narrow list would also miss subcommands the generated skills actually run (openspec archive, openspec feedback, openspec store), so the archive skill would start prompting again; if the wildcard feels too broad for your setup you can deny specific patterns in your own .claude/settings.json, and feel free to open an issue if you think the default should be tightened.

[clay-good]

Answered above by @clay-good. Short version:

allowed-tools only pre-approves; it never grants anything your permission settings would otherwise deny. So the wildcard trades prompts for convenience — it doesn't widen what the agent is capable of.

The narrower list would also break real flows: the generated skills call openspec archive, openspec feedback and openspec store, so the archive skill would start prompting again.

If the wildcard is too broad for your setup, deny specific patterns in your own .claude/settings.json — deny rules win over allowed-tools. And if you think the shipped default should be tightened, an issue is the right place for it.

Closing as answered — reopen if you'd like to take the default-tightening further.