Allowlist not detecting specific commands

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A certain number of specific commands entered into the allowlist are not recognized.

The expected behavior would be that, on Windows, for example, when items are separated by a semicolon in the shell, the initial terms are recognized. I believe this may not currently work in some cases.

For example, if multiple commands are separated by semicolons—such as go test, go lint, and something involving git status—and several commands are chained together, I believe recognition already fails even when each individual command and subcommand is included in the allowlist.

Additionally, even if complete commands, such as the one shown below, are added to the allowlist and then executed exactly as entered in the terminal, they are not recognized by the allowlist.

I therefore strongly assume that the allowlist is not fully prepared for all scenarios, such as chained commands on Windows using semicolons or, potentially, on Linux using double ampersands. I cannot confirm the Linux behavior. This may also apply to chained commands on Windows where additional statements are included.

It must be ensured that the allowlist fully covers all entries that are added to it.

go test ./…; if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }; go run -mod=readonly ./cmd/check-coverage

Steps to Reproduce

see desc

Operating System

Windows 10/11

Version Information

Version: 3.14.7 (user setup)
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Version: 3.14.7 (user setup)
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey there!

Quick unblock: wrap the sequence in a small script (e.g. check.ps1, or a make/npm/task target) and allowlist that single command. One entry matches, no prompt. Or switch to Auto-review mode (Settings → Agents → Approvals & Execution), which reviews commands semantically and handles PowerShell chains far better.

What’s happening: plain command chains do auto-run when each command is individually allowlisted (go test covers go test ./...). The prompt is triggered specifically by PowerShell control-flow syntax in the chain (if ($LASTEXITCODE ...) { ... }), which the allowlist doesn’t recognize today, so it errs on the side of asking. That’s also why adding the whole line verbatim doesn’t help - it’s matched per command, not as one entry. Nothing you misconfigured, and it’s an issue we’re tracking.

Let me know if the script-wrapping approach works for your setup!

8

Thank you very much for the response. Yes, that is exactly how I envisioned it working.

However, this is a major issue because, when working with it all day, you will find that LLMs continuously invoke different commands. Naturally, it is not possible to create a canonical script in the project for every single case. There are always new scenarios that need to be approved in the allowlist.

LLMs also naturally tend to start generically by chaining various if statements, echo commands, and so on. At the same time, proportionally speaking, the same types of actions keep recurring. This means it must be ensured that the behavior remains as it is now: when a command is approved, such as Go-Test, its subcommands and everything that follows must also be approved because the main parent command is recognized and therefore allowed.

However, it must also be ensured that complete code script blocks are recognized as a single command. As in the examples I mentioned above, it must be possible to insert something like this entirely via copy and paste.

Over a longer period of time and at scale, it cannot be ensured that separate scripts and similar solutions are created for everything. This means we must be able to add more complex one-line terminal scripts containing if commands, echo commands, and so on.