Command Allowlist: An entry naming a variable auto-runs any command on the right-hand side

[Leland_Hepworth]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The command allowlist is matched as a prefix/glob against the raw text of a command. Cursor never inspects the right-hand side of a shell variable assignment, so an allowlist entry that merely names a variable grants unattended execution to any command placed after the =.

With $out on the allowlist and Get-Random not in the allowlist:

Command	Result
Get-Random	Approval prompt
$out = Get-Random	Runs with no prompt

The four characters $out are the entire difference. Nothing after the = is examined, so the same entry equally covers $out = Remove-Item -Recurse C:\Temp or other more destructive and potentially malicious comamands.

The mechanism is in resources/app/extensions/cursor-agent-exec/dist/main.js (3.14.7). matchesShell falls through to four tests, and the second one is a raw-text prefix:

matchesShell(e, t) {
    const n = Wl(e);
    if (!n) return !1;
    const r = t.trim(),
        o = this.extractBaseCommand(r);
    if (null !== n.argsPattern) { /* ... */ }
    return !!this.matchGlob(n.fullPattern, r)
        || !!r.startsWith(`${n.fullPattern} `)   // <-- entry plus a space
        || !!this.matchGlob(n.fullPattern, o)
        || o === n.fullPattern;
}

$out = Get-Random starts with $out , so the second test returns true and the command is treated as fully approved. The rule appears to be intended for “entry is a command prefix and what follows is an argument list”, but it cannot tell an argument separator from an assignment operator.

The aggravating part is that Cursor creates these entries itself. Clicking “Always run” on a command containing a loop or a variable statement files the bare variable names as allowlist entries. Everyone should check their allowlist, as any entry begining with $ is a hole that allows the agent to run any command it wants as long as that variable is on the left-hand side.

Steps to Reproduce

Confirmed on 3.14.7 (Windows, PowerShell). No hooks or extensions are needed.

1. Open Settings → Agents → Approvals & Execution. Set Run Mode to Allowlist.
2. Under Command allowlist, add a single entry: $out
3. Confirm Get-Random is not on the allowlist.
4. Ask the agent to run Get-Random. → An approval prompt appears, as it should.
5. Ask the agent to run $out = Get-Random. → It runs with no prompt, and the tool result reports that it matched the command allowlist and ran outside the sandbox.
6. Replace the right-hand side with anything you like. $out = New-Item C:\Temp\proof.txt creates the file unattended, which shows the bypass is not limited to read-only commands.

Step 2 can also be reached without typing anything: click Always run on a command that contains a loop or a variable statement (such as the command from step #5), and Cursor files the bare variable names for you.

Expected Behavior

1. An assignment’s right-hand side is a command, and it should be matched against the allowlist on its own terms. $out = Get-Random should require approval exactly as Get-Random does. The left-hand side of the assignment (in this case $out) should not factor into the the allowlist’s decision to block the command.
2. The startsWith(entry + " ") test should not fire when the character that follows is an assignment operator rather than the start of an argument list.
3. Cursor should never file a fragment that is not a command as an allowlist entry. A bare variable name, a literal, an option, a property name, or a quoted string should be refused rather than stored, because it can only ever match by accident.

Operating System

Windows 10/11

Version Information

Version: 3.14.7 (system 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?

Not model-specific — this is terminal approval logic rather than model behavior. Observed while running

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Prior threads that establish the mechanism but not this case:

YOLO mode bypasses command allowlist using &&

I was testing out yolo mode with read-only commands using an allowlist. One of the commands I gave it access to was cd. I did not whitelist tofu apply (although I did give it access to other tofu commands: tofu plan, tofu show, etc.). The agent was able to execute cd tofu/cloud && tofu apply -auto-approve without my approval. Nothing bad happened in this scenario but obviously this is a pretty dangerous flaw. I’d caution anyone against running YOLO mode in any environment where harmful command…

Cursor not honoring command allowlist

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug I only have a small subset of commands allowlisted, and one of them is cd. Cursor is now able to run ANY command because it runs cd first into the directory, then &&'s another command. the allowlist clearly only looks at the first command (cd), so it allows it. Pretty brutal edge case Steps to Reproduce I only have a small subset of commands allowlisted, and one of them is cd. Cursor is now able to run ANY command because…

Those posts reported the same class of gap through command chaining, and the second was closed as fixed. So && is now split correctly while assignment is not.

Workaround, for anyone who finds this thread:

For now I have added a single deliberately broad entry $* to the allowlist, and introduced a beforeShellExecution hook that parses the command and returns ask unless every statement touches only session-local variables and commands already on the allowlist. That is a lot of custom code to buy back a guarantee the allowlist should already be providing. It is only possible because a hook’s ask overrides an allowlist match, which previously had issues but may be resolved now:

beforeShellExecution returns permission: "ask" but sandboxed Agent shell still runs the command (sandbox: true)

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug When the Agent runs a shell command via the Shell tool, beforeShellExecution fires and returns {“permission”:“ask”}, but the command still executes in the same turn. The hook payload includes “sandbox”: true, which suggests the sandboxed Agent shell path may not be gating on hook permission the same way as non-sandbox / interactive shell. Steps to Reproduce Configure beforeShellExecution to return {“permission”:“ask”} for…

Does this stop you from using Cursor

No - Cursor works, but with this issue

[mohitjain (Mohit)]

Hey @Leland_Hepworth,

For now, in Settings → Agents → Approvals & Execution, stick to allowlisting concrete commands you intend (and prune anything that looks like a short token or variable-style entry). Your beforeShellExecution hook that forces ask is a good extra check. More on the controls here: Run Modes.

We’ve let the team know. I’ll post here if there’s something useful to share.