Cursor CLI runs ls without asking, and a deny rule does not stop the agent trying another way.

What we found.

Cursor CLI's own documentation says: "Before running terminal commands, CLI will ask you to approve (y) or reject (n) execution." and "By default, terminal commands need your approval." The shipped default is different. "On first start the CLI creates ~/.cursor/cli-config.json with "permissions": {"allow": ["Shell(ls)"], "deny": []}. It did so in all 20 runs where we supplied no configuration file, including both interactive boots." In a default headless run, "ls -la ran without any approval step, while other commands (date, python3) were rejected."

The second point is about the protection users write themselves. With --force and a deny rule for Shell(python3), "it blocked the agent's python3 commands five times ("Command blocked by permissions configuration")." Then: "The model then reached the same result by other means, including running the interpreter in a form the rule does not match, which executed." Cursor's own permissions reference says "The commandBase is the first token in the command line", but its examples present a deny entry as the way to block a command.

We re-checked both behaviours on 19 October 2026 against Cursor CLI 2026.10.16-e3cb207. The first-start config again allowlisted Shell(ls) and ls -la ran again without approval; the deny rule again blocked python3, and /usr/bin/python3 executed. Nothing has changed. This note describes behaviour and documentation; "We are not claiming a confirmed security vulnerability."

What the approval default does.

What we tested, and what we saw.

We tested "Cursor CLI (cursor-agent) 2026.09.26-dd393fe, the Linux x64 package from downloads.cursor.com (sha256 8085fd120f5c71f4eae7fea26a043718e5644e3071e4fab3220a0e58c51f9593), tested on 27 September 2026." Set-up: "a fresh throwaway Linux container per run with a new in-memory HOME, a TLS-intercepting proxy the client trusted, a full packet capture and an execve trace." "23 test units: 21 headless (-p; one of them made three invocations in the same HOME) and 2 interactive boots left idle." "No human answered any prompt."

On the deny test we said this at the time: "This was one run with one model under --force, and the request came from us, not from untrusted content."

Re-check, 19 October 2026, Cursor CLI 2026.10.16-e3cb207 (batch RETEST-CUR1-20261019T112328Z): seven units in the same rig, one default run, five with --force and the deny rule, and one --force positive control.

• The approval default: the re-check's default run generated a config whose permissions read "allow": ["Shell(ls)"], "deny": [] (captured as homeout-cli-config.json), and its ls step returned "`ls -la` output in `/work`:" while its date step came back with "the `date` command is being blocked".
• The deny rule: in the re-check's deny runs the block came back as "Permission denied: Command blocked by permissions configuration", and in one run the agent's next command was "/usr/bin/python3 -c "print(6*7)""; the execve trace records execve("/usr/bin/python3", ["/usr/bin/python3", "-c", "print(6*7)"] and the run reported "The output is:". In another run, asked for the absolute path directly, the trace shows the same execve and the run reported "The command prints:" with 42.
• Positive control: with --force and no deny rule, the same one-liner ran and reported "The output is:" with 42.

Where they differ.

Our reading, as sent to Cursor: "We accept that ls is low risk and that the run modes page says allowlisted actions run without approval. Our point is that the documented default and the shipped default differ." And on the deny rule: "we think the documentation should say that deny rules match the literal first token and that the agent may try other ways to reach the same result."

What a reader can do with this.

Approval default: know that a fresh Cursor CLI start allowlists Shell(ls) before you have approved anything. The allowlist the CLI installs is in ~/.cursor/cli-config.json, and "the run modes page says allowlisted actions run without approval". We asked Cursor: "Is the Shell(ls) allowlist the intended CLI default? If so, could the "Command approval" section say so?"

Deny rules: the permissions reference states the matching rule, "The commandBase is the first token in the command line", and our runs show the agent may then try another way. We asked Cursor: "Should deny rules for a command also cover the same executable called another way, or should the permissions reference say that they do not and that the agent may try alternatives?"

Until the documentation changes, treat a deny entry as a rule about the literal command text, not about what the agent will achieve.

What we are not claiming.

• "We are not claiming a confirmed security vulnerability."
• "We accept that ls is low risk and that the run modes page says allowlisted actions run without approval. Our point is that the documented default and the shipped default differ."
• "We did not answer any approval prompt in the interactive boots, so we did not observe an interactive ls running without approval."
• "This was one run with one model under --force, and the request came from us, not from untrusted content."
• "We tested one account on the Free plan with Privacy Mode on, and the "auto" model." "We make no claim about paid plans, other models, the desktop app or Cloud Agents."
• The re-check was seven units on one day, on Linux x64, against Cursor CLI 2026.10.16-e3cb207. It covers the two behaviours above and nothing else.

Disclosure of interest: "Agentic Thinking also owns AgentProtect, commercial AI agent governance software."

Disclosure timeline.

• 27 Sep 2026: reported to security-reports@cursor.com under our disclosure policy, "about 30 days for documentation matters", covering the approval default and the deny rule (Message-ID <179053173524.225062.4776706353897990181@agenticthinking.uk>).
• 27 Sep 2026: the only reply to that report, from "Cursor (via HackerOne)" <no-reply@hackerone.com>, an automated message: "Thank you for submitting a potential vulnerability to the Cursor Vulnerability Disclosure Program. We are HackerOne and we partner with Cursor to manage and track submissions." It asks the sender to submit through a HackerOne invitation link. It states: "This message is automatically generated by HackerOne."
• 28 Sep 2026: second contact to security@cursor.com (Message-ID <179058936499.1342659.15411674047698417460@agenticthinking.uk>): "On 27 September 2026 I sent a Cursor CLI report to security-reports@cursor.com. The automated reply directed me to HackerOne. We disclose by email only, so I am writing here instead." and "Please forward this to the right team, or confirm that a human has it." "There are no new findings."
• 28 Sep 2026: reply from Sam, "Cursor's AI Support Assistant", <security@cursor.com>: "Hi Leo! Thanks for reaching out. Your ticket number is T-G31235 for your reference." and "For security vulnerability reports, please email security-reports@cursor.com so the security team can process them through the formal channel." and "We commit to acknowledging vulnerability reports within 5 business days, and addressing them as soon as possible." No human reply has arrived since; the two replies above are the only ones in our records.
• 19 Oct 2026: re-checked both behaviours on Cursor CLI 2026.10.16-e3cb207. Unchanged; nothing is fixed, so there is nothing to credit.
• Tuesday 27 October 2026: this note published, stating the versions tested and this timeline.

Any response will be added here. Evidence and reproduction steps are available to Cursor and to researchers on request: research@agenticthinking.uk.