Bug: terminalAllowlist forces Allowlist mode and disables Auto-review

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug: terminalAllowlist forces Allowlist mode and disables Auto-review

Summary

Adding a terminalAllowlist key to ~/.cursor/permissions.json forces Cursor into Allowlist mode and disables or grays out Auto-review mode. This prevents users from combining deterministic terminal permissions with Auto-review’s classifier.

Environment

  • Cursor IDE
  • macOS 15.6
  • Cursor configuration: ~/.cursor/permissions.json
  • Observed: August 3, 2026

Impact

This makes it impossible to use exact command allowlisting together with Auto-review. Users must choose between:

  • Auto-review, where safe commands may still repeatedly require approval; or
  • Allowlist mode, where classifier-based review is unavailable.

The behavior is also surprising because the permissions documentation describes terminalAllowlist and autoRun as separate configuration fields, without clearly stating that defining terminalAllowlist disables Auto-review.

Suggested fix

Either:

  1. Allow Auto-review and terminalAllowlist to work together, or
  2. Clearly document that terminalAllowlist forces Allowlist mode and add an explanatory warning when the key is detected.

A possible warning:

terminalAllowlist is configured in permissions.json. This overrides the IDE terminal allowlist and disables Auto-review for terminal commands. Remove this key to use Auto-review.

Steps to Reproduce

Reproduction steps

  1. Open ~/.cursor/permissions.json.
  2. Add a terminalAllowlist, for example:
{
  "autoRun": {
    "allow_instructions": [
      "Allow routine read-only git commands."
    ],
    "block_instructions": [
      "Require approval for destructive git operations."
    ]
  },
  "terminalAllowlist": [
    "git status",
    "git diff"
  ]
}
  1. Return to Cursor’s Agent settings.
  2. Open the run-mode or approval settings.

Actual behavior

  • Cursor forces the terminal behavior into Allowlist mode.
  • Auto-review mode is disabled, unavailable, or grayed out.
  • autoRun.allow_instructions and autoRun.block_instructions cannot be used as intended because Auto-review is no longer selectable.
  • Removing terminalAllowlist restores Auto-review mode.

Expected Behavior

Expected behavior

terminalAllowlist should configure the terminal allowlist without forcing the entire Agent run mode to Allowlist.

Users should be able to choose either:

  • Auto-review mode, with terminalAllowlist entries treated as trusted commands and autoRun instructions steering the classifier; or
  • Allowlist mode, where only explicitly allowlisted terminal commands run automatically.

At minimum, Cursor should explain in the settings UI that defining terminalAllowlist forces or overrides the selected run mode.

Operating System

MacOS

Version Information

Version: 3.14.7
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: Agent Window
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: Darwin arm64 25.6.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. The step-by-step breakdown and config really helped.

Here’s what’s going on. This is reproducible and not related to your setup. As soon as a non-empty terminalAllowlist shows up in ~/.cursor/permissions.json, Cursor treats that file as a deterministic policy and locks the mode to Allowlist. Because of that, Auto-review becomes unavailable, and the autoRun allow/block rules stop working. You were right that removing terminalAllowlist brings Auto-review back.

There’s a workaround that gives you exactly what you want, a deterministic allowlist plus the Auto-review classifier:

  • Keep your autoRun allow/block rules in ~/.cursor/permissions.json.
  • Remove terminalAllowlist from there.
  • Move the commands from terminalAllowlist into the IDE allowlist: Settings > Agents > Approvals & Execution.

The key difference is that an allowlist set via IDE Settings gets combined with Auto-review. Allowlisted commands auto-run deterministically, and everything else goes through the Auto-review classifier. Only the permissions.json path forces Allowlist-only. This is also described in the enterprise deployment docs: if the key is missing or empty, Cursor falls back to the editor-managed allowlist for that category.

Important: don’t use approvalMode: "unrestricted" as a workaround. It locks the run mode and makes the dropdown read-only.

On the second part, I agree that the interaction between terminalAllowlist and Auto-review isn’t covered in the docs, and the banner doesn’t warn about it. I’ve passed this to the team as documentation and UX feedback. I’ll follow up here if there’s an update. Let me know if the workaround doesn’t fit your use case.

7

I don’t believe that is a workaround, since permissions.json allows for sub commands like git add without allowed git push but the IDE settings only respects entire binaries.

8

Following up here! Thanks :slight_smile:

9

Your objection still stands, and honestly you pointed to the exact gap this fix is supposed to cover. The IDE allowlist works at the binary level and doesn’t give the subcommand-level control that terminalAllowlist in permissions.json supports, like allowing git status and git diff but not git push. So I can’t recommend it as a replacement for your use case. Right now we can’t do a checked-in granular allowlist together with Auto-review.

To summarize clearly:

  • terminalAllowlist in permissions.json gives the granularity you need, but it switches the mode to Allowlist and disables Auto-review.
  • The IDE allowlist keeps Auto-review, but loses subcommand-level precision.
  • You can’t combine the two right now, and that’s the limitation we’re tracking.

approvalMode: "unrestricted" still isn’t an option. It’s not a supported field and it breaks Run Mode control.

I’ve also shared the point about needing granular allowlist plus Auto-review with the team separately from the docs banner topic. This is missing functionality, not just a docs issue. There’s no timeline yet, but I’ll post here if there’s an update.

10

You should update your documentation since it currently states that the two modes are combinable, thank you. I do think this is a real unintentional gap that should be mitigated. Thanks.