microsoft / microsoft/vscode

Terminal auto-approve: exact-command-line rules are case-sensitive for PowerShell and dropped on parse failure

Open
#328,109 0 comments 0 reactions 1 assignee Claimed by @anthonykim1 View on GitHub
bug terminal
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

Follow up to #328052. Two related defects in the workbench's exact-command-line auto-approve rules, both of which reproduce the original "I clicked Always Allow and it asked again" symptom.

## 1. The persisted rule is case-sensitive, but PowerShell is not

`generateAutoApproveActions` in `runInTerminalHelpers.ts` persists:

```js
key: `/^${escapeRegExpCharacters(commandLine)}$/`
```

with no `i` flag. `CommandLineAutoApprover` does build a `regexCaseInsensitive` variant and uses it for PowerShell sub-command matching (`_commandMatchesRule`), but `isCommandLineAutoApproved` always uses the case-sensitive `rule.regex`.

So a user who clicks **Always Allow Exact Command Line** on `Get-ChildItem -Path .` is prompted again when the model next emits `get-childitem -Path .`, even though PowerShell treats them identically.

The same asymmetry exists in the Agent Host approver (`_matchesRule` takes `isPowerShell` as an *optional* parameter and the two command-line call sites omit it). Making that parameter required would force the decision to be explicit at each call site rather than by omission.

## 2. Exact-command-line rules are silently dropped when the parse fails

`commandLineAutoApproveAnalyzer.ts` returns early on `!subCommands?.length`, **before** `isCommandLineAutoApproved` is ever consulted. A command line the grammar cannot parse therefore can never be auto-approved, no matter what the user configured.

Combined with #328108 this is the worse of the two: the ~8% of realistic commands the PowerShell grammar cannot parse (bare `--` separator, leading `./path`) prompt forever, *and* the "Allow Exact Command Line" button the user reaches for does not help.

A `matchCommandLine` rule is an anchored, explicitly user-authored match against the whole command line, so it does not depend on a usable parse and can safely be evaluated first. Deny-command-line rules must still be checked before allow rules.

## Fix applied in Agent Host (for reference)

`commandAutoApprover.ts` now evaluates deny-command-line rules, then attempts the parse, and on parse failure falls back to allow-command-line rules before returning `noMatch`. Covered by a test asserting both the allow and deny direction for `git diff -- src/` (which the PowerShell grammar cannot parse).

Item 1 is not yet fixed on either side.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.