[FEATURE]: Add a way to choose "exact command" vs. "pattern" when granting always-allow

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

Right now, choosing "always allow" on a bash permission prompt only ever saves a widened pattern — e.g. approving git status installs git status *, not the literal command. There is no way to lock an approval to the exact command string.

This means every "always allow" is implicitly a prefix/family grant, whether the user wants that or not:

• It's unsafe by design: approving a compound command generates a separate allow rule for every sub-command in it from a single click. Approving git status && rm -rf ./tmp doesn't just approve that one compound line — it separately installs git status * and rm * as independent standing rules. The second one then matches any later rm command on its own, including rm -rf /, even though the user never reviewed or approved a bare rm command (#40158).
• There is currently no workaround that preserves the session-scoped, low-friction nature of "always allow." The only way to get exact-string matching today is to manually edit opencode.json outside the prompt flow — which installs a permanent, cross-session rule rather than a temporary one, and still doesn't address the compound-command case, which installs multiple rules regardless of how the pattern was authored.

Request

Give users a way to grant an "exact command" approval — one that matches only the literal command string, no prefix/wildcard expansion — as an alternative to the current always-widened pattern grant. Leaving the UI to maintainers' judgment: a second top-level prompt option, a submenu off "always allow," a modifier, or a config default are all reasonable shapes. What matters is that "exact" and "pattern" become two selectable outcomes rather than pattern-widening being the only path.

For compound commands (&&, ;, |), the exact-match mode should store the whole compound string as one literal rule, rather than splitting it into per-subcommand grants — so approving git status && rm -rf ./tmp exactly does not also silently allow rm -rf /some/other/path later.

Why this is different from #24795 / #25089 (both closed as not planned)

Those requests asked to let users edit the generated pattern text in the prompt before confirming — essentially a freeform text field for tuning the wildcard. This request is narrower and doesn't require that: it's a fixed binary choice (literal string vs. current auto-widened pattern), not an open-ended pattern editor. If the earlier closures were about UI/scope concerns with a freeform editor, a two-mode toggle is a smaller, more constrained surface and may not carry the same objections — but flagging the prior closures here so maintainers can clarify if the concern was more fundamental (e.g. not wanting to complicate the prompt at all).

Related work

• #24795, #25089 — closed as not planned. See distinction above.
• #47369 — merged. Adds a preview of the generated pattern before confirming, but doesn't add an exact-match choice; the previewed pattern is still always the widened one.
• #40158 — open. Documents the compound-command over-grant this request would help prevent.
• #16914 — closed as not planned. Raised this same "Always (Exact Same)" idea as a secondary aside within a broader config-support question; never evaluated as its own feature request. Filing this separately so it can be judged on its own merits.
• Prior art in a different tool: RooCodeInc/Roo-Code#11095 proposes/implements the same exact-vs-prefix distinction, motivated by the same class of risk (git show → git show > ~/.ssh/id_rsa).