cursor is not following ANY of my .mdc files, or allow lists, or any of the rules for documentation in a project. ITIL / Items creation and closer is vital to compliance. Why doesn’t it read or ever follow the structures our team puts in place??
we have edited permissions files and all been specific on .mdc files - the Allow List is CONSTANTLY ignored… Updated on local machines and in the root for the project. NOTHING MATTERS
Why is there no paid support?
Hey, let’s break this down. There are two separate things here.
Rules are mixed into the prompt as guidance, not as a hard constraint. Whether they reliably make it into context depends on the rule type:
alwaysApply: true at the workspace root. The body is injected every turn.globs: only when the agent reads a matching file.description:. The agent sees the description and decides whether to read the body.A common reason rules feel ignored is that they are not alwaysApply: true or they live in a nested folder so they are treated as file scoped. Check each rule type in Settings → Rules and move anything critical for compliance to Always at the repo root. More details: Rules | Cursor Docs
You are currently in Auto-review mode by default. In this mode, commands that can be sandboxed get sent to the sandbox and run without checking the allowlist, so it looks like the allowlist is not working. This is by design, see the discussion: Command Allowlist is silently ignored when "Auto-Run in Sandbox" is enabled
Another detail: the shell allowlist is only read from the global ~/.cursor/permissions.json. The project .cursor/permissions.json is not used for command gating right now. This is a known limitation and has been reported, there is no ETA yet. That is why it feels like changing things in the project root does nothing.
For strict per command control:
On personal Pro you do not get admin enforced rules or a locked auto-run policy. That is only on Team or Enterprise. If you need to centrally enforce rules and permissions for compliance across a team, you need Team, Business, or Enterprise. Those plans also include dedicated support channels.
If after moving rules to Always and switching to Allowlist it still does not follow them, share the Request ID menu in the top right of the chat > Copy Request ID, your run mode, and the frontmatter from one of the rules, and we can dig deeper.
THank you for the response Dean -
Here is an example 1 minute ago of the absolute failure.
It is nearly impossible to make any progress. I’ve updated persmissions.json at the app level and in this repo. The cursor tool works for 15 seconds, and then yet another item on the approved list is blocking even the simplest steps forward.
Here is my AllowList
“terminalAllowlist”: [
“bash”, “biome”, “bun”, “cargo”, “cat”, “cd”, “cf”, “cmd”, “corepack”, “curl”, “curl.exe”,
“deno”,
“docker”,
“doppler”,
“echo”,
“esbuild”,
“eslint”,
“ConvertFrom-Json”,
“Select-Object”,
“Where-Object”,
“ConvertTo-Json”,
“Select-String”,
“Remove-Item”,
“Get-Children”,
“Get-ChildItem”,
“Get-Content”,
“Stop-Process”,
“Start-Sleep”,
“Test-Path”,
“gh”,
“git”,
“go”,
“jq”,
“make”,
“lint”,
“n”,
“n-”,
“node”,
“npm”,
“npx”,
“pip”,
“pnpm”,
“poetry”,
“powershell”,
“prettier”,
“pwsh”,
“py”,
“python”,
“sh”,
“tsc”,
“tsx”,
“turbo”,
“uv”,
“vite”,
“vitest”,
“wrangler”,
“wsl”,
“yarn”
I expand it constantly - nothing seems to work…
Thanks for the extra info. The key clue in your screenshot is that it shows Run Everything mode, but the command is still stuck on approval with Not in allowlist: curl.exe. In Run Everything, commands should not be checked against the allowlist at all, everything should run without approval. If the check is happening, then the effective mode is not actually Run Everything, even if the UI shows it.
The most common reason for this mismatch is that if you click Add to allowlist in the approval card while you are in Run Everything, the mode quietly switches to Use Allowlist. The UI can still keep showing the old value. Less often, the mode state gets stuck in local storage and overwrites what you picked in settings.
What to do step by step:
About matching itself. Even in Allowlist mode, curl.exe from the list should match curl.exe ... since matching is prefix based. If it does not match, it is almost for sure reading the wrong file. The shell allowlist is only taken from the global permissions.json or from Settings → Agents → Approvals & Execution. The canonical path on Windows is %USERPROFILE%\.cursor\permissions.json. If the file is not there, look for the .cursor folder in your home directory or tell me the path that actually opens from Settings. The project .cursor/permissions.json at the repo root is not used for gating right now.
To finish the diagnosis, please share what is missing from the screenshot:
terminalAllowlist lives