Allowlist / Always Run still prompts for commands already on the Command Allowlist (3.15.19 Linux)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor: 3.15.19 (de07bee81cefe43461ebf4f40c3d2d78d15052a0)
OS: Linux 7.0.0-28-generic x86_64
Run Mode: Allowlist (NOT “Allowlist with Sandbox”, NOT Auto-Review)
Plan: Teams (team admin). Auto Run Configuration is Enterprise-only in the dashboard.

Expected

  • A command already on Command Allowlist runs with no approval card
  • Always Run persists that command so the next run is silent
  • The approval card must not ask to Always Run a binary that is already a chip on the list

Actual

  1. Always Run sometimes does not persist. Clicked Always Run for systemctl --user is-system-running multiple times. composerState.yoloCommandAllowlist in ~/.config/Cursor/User/globalStorage/state.vscdb did not gain systemctl (count stayed 102; newest were hostname/free). Later it appeared (count 103) after another attempt / manual Add commands. Same UI action, inconsistent write.

  2. Card asks to re-add tools already on the allowlist. With both systemctl and python3 already chips, agent ran:
    systemctl --user is-system-running && python3 - <<‘PY’

    read ~/.config/Cursor/User/globalStorage/state.vscdb

    PY
    UI still showed “Always run these commands” listing systemctl and python3.

  3. Bare allowlisted command works. After systemctl was on the list, bare systemctl --user is-system-running matched allowlist and ran with no card. List is loaded; compound / some Always Run paths are wrong.

Also: "$HOME/.dotnet/dotnet" --version prompted despite $HOME/.dotnet/dotnet already allowlisted; Always Run saved a second quoted chip.

Repro

  1. Settings → Agents → Approvals: Run Mode = Allowlist
  2. Ensure systemctl and python3 are on Command Allowlist
  3. Agent runs a compound systemctl … && python3 <<'PY'…
  4. Observe prompt offering Always Run for systemctl / python3 again
  5. Separately: Always Run on some cards does not appear in yoloCommandAllowlist afterward

Related staff-acked threads on Always Run / chained allowlist matching (redirects, ; chains) on 3.14.x.

Steps to Reproduce

  1. Cursor Settings → Agents → Approvals & Execution → Run Mode = Allowlist (not “Allowlist with Sandbox”, not Auto-Review).
  2. Add systemctl and python3 to Command Allowlist (or confirm they are already chips).
  3. In Agent chat, have the agent run: systemctl --user is-system-running
    → Often shows Always Run; clicking Always Run sometimes does NOT add systemctl to yoloCommandAllowlist in state.vscdb.
  4. Manually ensure systemctl and python3 are on the allowlist.
  5. Have the agent run a compound command:
    systemctl --user is-system-running && python3 - <<‘PY’
    print(“ok”)
    PY
  6. Observe approval card offering “Always run these commands” for systemctl and/or python3 even though both are already on the list.
  7. Have the agent run bare systemctl --user is-system-running again → may run silently (allowlist match), showing the list is loaded but matching/Always Run for compound (and some Always Run clicks) is wrong.

Expected Behavior

  • Commands already on Command Allowlist never show an approval card.
  • Always Run always persists the command to the allowlist so the next identical run is silent.
  • Approval cards must not ask to Always Run a binary that is already a chip on the list.

Operating System

Linux

Version Information

Cursor: 3.15.19
Commit: de07bee81cefe43461ebf4f40c3d2d78d15052a0
OS: Linux 7.0.0-28-generic x86_64

For AI issues: which model did you use?

Auto Cost

For AI issues: add Request ID with privacy disabled

Request ID: 18cffb08-6a66-4f6b-be02-f86d4f84b2cc

Additional Information

Teams plan (team admin). Run Mode Allowlist without sandbox. Allowlist chips persist in composerState.yoloCommandAllowlist. Bare allowlisted commands can match; compound commands and some Always Run clicks still prompt / fail to persist. Related: quoted “$HOME/.dotnet/dotnet” vs $HOME/.dotnet/dotnet.
Agent/chat id: a4dcb4a1-ff8b-4db5-bd63-119e873f75e3

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Thanks for the detailed repro, Liam. This isn’t intended, and it isn’t something you misconfigured. We’ve let the team know. In Allowlist mode, a command that chains && into a heredoc (like systemctl … && python3 - <<'PY') can still prompt even when both commands are already on the Command Allowlist. A command that is already on the list should run with no prompt when it is sent on its own. The extra prompt shows up on the chained heredoc form.

Until there’s a fix, run them as two separate agent commands, or use a one-line python3 -c '…' in the chain instead of a heredoc. Allowlist matching is also literal, so "$HOME/.dotnet/dotnet" and $HOME/.dotnet/dotnet are different entries. Add the exact string the agent runs if you want that invocation covered.

We’ll post any relevant updates here when we have them.

8

Follow-up (still on 3.18.9 Linux) — related failure in Always Run’s “Will allow” suggestion

Original report: compound commands still prompt / offer Always Run for tools that are already on Command Allowlist.

New repro (same Allowlist mode, not Sandbox / not Auto-Review):

Agent proposed a chain like:

node scripts/generate-skill-policies.mjs && pwsh -NoProfile -Command ‘…’ && pwsh -NoProfile -File …/PruneMigrationDesigners.ps1

Approval card tooltip Always run these commands → Will allow:

  • node only

Verified against composerState.yoloCommandAllowlist at the time:

  • node was already on the allowlist
  • pwsh was not on the allowlist

So the card prompted for a chain whose real missing token was pwsh, but Always Run offered to persist only node (already allowed) and omitted the actual blocker.

That’s worse than “re-prompt for already-listed tools”: Always Run’s suggested entries can be incomplete/wrong, so clicking Always Run does not unblock the next identical run.

Happy to attach a Request ID from Report AI Action if useful.

image
image614×180 39.4 KB