Allow commands to be approvable per-invocation but never persistently ('always approve' opt-out)

[RafalK-CreateFuture]

Describe the feature or problem you'd like to solve

There is currently no way to mark a command as approvable but never rememberable. Every approval prompt offers a persistent "always approve in this directory" option, including for irreversible, remote-effect commands such as git push. A single misclick silently grants that command forever, and nothing afterwards surfaces that the grant exists.

Proposed solution

Add a setting that lets users nominate commands which may always be approved per invocation, but for which the persistent "always approve" option is withheld entirely — the option simply isn't offered.

Something like:

// ~/.copilot/settings.json
{
  "neverPersistApprovals": ["git push", "gh pr merge", "kubectl delete", "terraform apply"]
}

Behaviour: the normal approval prompt still appears and can be accepted, so nothing is blocked. Only the persistence option is suppressed for the listed commands.

This reflects a real distinction the current model misses. Approving sed or ls forever is a convenience win. Approving git push forever changes the blast radius of every future session, because its effects leave the machine and cannot be undone locally. Treating both with the same UI affordance means the highest-stakes decision is exactly one keystroke away from being permanent.

Why not just curate the config by hand? Today that is the only remedy, and it has three problems: the grant is invisible unless you go looking for it; the file is large and hand-editing is error-prone; and it is reactive — you discover the grant only after it has already allowed something you didn't intend.

Related: approvals are scoped to the session cwd, not the repo being acted on

This may warrant a separate issue, but it compounds the above and is how I hit it.

Approvals in permissions-config.json are keyed to the session's working directory. If a session starts in a directory with a git push grant, that grant applies to any repository the agent touches during the session — including repositories elsewhere on disk that have no grant of their own.

Concretely: I had git push approved for a directory containing several of my own projects. In a session started there, the agent operated on a repo in a completely different location, one with no push grant. The push went through with no prompt, because approval was resolved against the session cwd rather than the repo being pushed. Tools like git -C and --git-dir make this trivially reachable without the agent ever changing directory.

I'd expect a directory-scoped approval to apply to work in that directory. Resolving VCS commands against the target repository — or at minimum re-prompting when the target falls outside the approved path — would match the mental model the UI implies.

Example workflows this would enable

1. Approve git push case by case for months without a stray click making it permanent.
2. Let a teammate or contractor run the CLI knowing destructive commands can never become silently pre-approved.
3. Keep broad convenience grants (sed, find, python) for a directory while a small deny-persistence list covers the handful of commands with external side effects.
4. Shared or managed configs: an organisation ships a baseline list so irreversible operations always prompt, without blocking anyone's workflow.

Additional context

• Today the only workarounds are periodically scrubbing permissions-config.json, or a sessionStart hook that strips the entry — both reactive, and both easy to forget.
• Server-side branch protection catches the git push case specifically, but it is per-repo, out of the CLI's control, and does nothing for kubectl delete, terraform apply, or similar.
• Possibly relevant to Epic: Permissions Improvements #316 (Epic: Permissions Improvements).
• A simpler variant, if a configurable list is too much: never offer persistent approval for a small built-in set of known-irreversible commands, with an opt-out for users who want the current behaviour.

CLI version: 1.0.88