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

**URL:** <https://forum.cursor.com/t/allowlist-always-run-still-prompts-for-commands-already-on-the-command-allowlist-3-15-19-linux/168423>\
**Category:** Bug Reports\
**Tags:** terminal, auto-run\
**Created:** [August 14, 2026, 4:02pm UTC](https://forum.cursor.com/t/allowlist-always-run-still-prompts-for-commands-already-on-the-command-allowlist-3-15-19-linux/168423 "2026-08-14T16:02:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![LiamCooper](https://avatars.discourse-cdn.com/v4/letter/l/47e85d/32.png) [@LiamCooper](https://forum.cursor.com/u/LiamCooper)\
**Post date:** [August 14, 2026, 4:02pm UTC](https://forum.cursor.com/t/allowlist-always-run-still-prompts-for-commands-already-on-the-command-allowlist-3-15-19-linux/168423/1 "2026-08-14T16:02:34Z")

</div>

### 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’

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

---

<div class="post-metadata">

**Author:** ![kevinn](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kevinn/32/101206_2.png) [@kevinn](https://forum.cursor.com/u/kevinn)\
**Post date:** [August 17, 2026, 9:50pm UTC](https://forum.cursor.com/t/allowlist-always-run-still-prompts-for-commands-already-on-the-command-allowlist-3-15-19-linux/168423/7 "2026-08-17T21:50:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![LiamCooper](https://avatars.discourse-cdn.com/v4/letter/l/47e85d/32.png) [@LiamCooper](https://forum.cursor.com/u/LiamCooper)\
**Post date:** [September 1, 2026, 11:40am UTC](https://forum.cursor.com/t/allowlist-always-run-still-prompts-for-commands-already-on-the-command-allowlist-3-15-19-linux/168423/8 "2026-09-01T11:40:26Z")

</div>

**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](https://us1.discourse-cdn.com/cursor1/original/3X/e/d/ed4d668500f1c2759793cea472aee8f8bd9dd11c.png)