Make read-search tools (Grep, Glob) restrictable in CLI permissions

Ideas Feature Requests
, ,
1

Feature request for product/service

Cursor CLI

Describe the request

The CLI permission vocabulary is Shell(commandBase), Read(pathOrGlob),
Write(pathOrGlob), WebFetch(domainOrPattern) and Mcp(server:tool).
Read can be denied by path – but Grep and Glob return the same bytes and the same file
listings, and they are not covered.

Measured on 2026.09.02-c22c1a3 (Windows 11)

With this cli-config.json:

{ "permissions": { "deny": ["Read(**)", "Shell(**)", "Write(**)", "WebFetch(**)"],
                   "allow": [] } }

and the workspace set to an empty directory:

  • Read of a file outside the workspace (absolute path) → correctly denied
    (Error: Permission denied)
  • Glob of the same absolute directory → succeeded, listed its files
  • Grep of the same absolute directory → succeeded, returned the matching line

The agent itself reported which tool it used (“Grep を使いました” / “I used Grep”).
So the deny-by-path model already works; it simply does not reach the search tools.

Also tried, none of which restricted Grep/Glob:

  • naming them explicitly: deny: ["Grep(**)", "Glob(**)"]
  • a catch-all: deny: ["*"]
  • dropping --trust
  • approvalMode: "default"

Use case

Running the CLI as an isolated reviewer that must see only the material it was handed, and
nothing else on the machine.

This is not about preventing damage – writes and shell are already restrictable, and I
confirmed a delete was correctly refused with deny: ["Write(**)"]. It is about bounding
reading, which is what the independence of a review depends on: a reviewer that can read
another reviewer’s verdict, or the material of a different round, is no longer independent.

Suggested shape

Extend the existing vocabulary rather than adding a new concept, e.g. Grep(pathOrGlob) and
Glob(pathOrGlob), denied and allowed the same way Read already is.

Why not hooks

Hooks can express this today in principle – I verified preToolUse does match Read, Grep
and Glob. But on Windows with Git Bash the hook never runs (the PowerShell decoder snippet
is handed to bash), so the hook fails and every matched call is reported as “Hook blocked”:

A permission model that only holds when hooks happen to work is fragile for this use case.
The two mechanisms also serve different purposes: permissions are declarative and reviewable,
hooks are code.

If there is an existing way to restrict Grep/Glob that I missed, I would be glad to be
corrected.

Operating System (if it applies)

Windows 10/11