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

**URL:** <https://forum.cursor.com/t/make-read-search-tools-grep-glob-restrictable-in-cli-permissions/170949>\
**Category:** Feature Requests\
**Tags:** cli, auto-run, hooks\
**Created:** [September 7, 2026, 6:10pm UTC](https://forum.cursor.com/t/make-read-search-tools-grep-glob-restrictable-in-cli-permissions/170949 "2026-09-07T18:10:54Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![hanyu\_masashi](https://avatars.discourse-cdn.com/v4/letter/h/43a26b/32.png) [@hanyu\_masashi](https://forum.cursor.com/u/hanyu_masashi)\
**Post date:** [September 7, 2026, 6:10pm UTC](https://forum.cursor.com/t/make-read-search-tools-grep-glob-restrictable-in-cli-permissions/170949/1 "2026-09-07T18:10:54Z")

</div>

### 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`:

```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”:

> [@Hooks never run in cursor-agent CLI on Windows + Git Bash — the failure becomes a silent hard deny (still repro on 2026.09.02)](https://forum.cursor.com/t/hooks-never-run-in-cursor-agent-cli-on-windows-git-bash-the-failure-becomes-a-silent-hard-deny-still-repro-on-2026-09-02/170945):
>
> Where does the bug appear (feature/product)? Cursor CLI Describe the Bug Hooks configured in .cursor/hooks.json never run in the CLI on Windows when Git Bash is present. Instead of running, the tool call is reported to the agent as “Hook blocked”. The command Cursor builds is PowerShell, but it is handed to bash: --: eval: line 1: syntax error near unexpected token `&' `$OutputEncoding = [System.Text.Encoding]::UTF8; Get-Content -LiteralPath '...\cursor-hooks-XXXX\payload.json' -Raw | & { $i…

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