Allowlist should not extend to redirects

Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When you add a command to the allowlist, Cursor apparently extends that authorization to file redirects.

Case in point, the following horror story:
Step 1: I added “grep” and “echo” to the Allowlist, just so that Cursor could search through files more quickly
Step 2: Cursor started damaging my .zshrc with echo >> .zshrc to workaround a problem it had encountered.

Steps to Reproduce

  1. Add echo to the Allowlist
  2. Ask about something that could be fixed by adding something to a configuration file
  3. Watch Cursor add that using echo >> config-file without asking to edit the file

In my case, Cursor seems to have done this multiple times, starting with adding GDK_BACKEND=x11 to address a warning that Emacs shows when running the GDK build over ssh / X11. It’s a good thing I keep these configuration files under version control.

Expected Behavior

When adding a command to the Allowlist, that should not extend to a command that has a file redirection. More precisely, doing so should be seen as an edit of the file and ask for confirmation that you want to edit the file.

Screenshots / Screen Recordings

Overwriting zshrc.jpg
Overwriting zshrc.jpg909×483 74.9 KB

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.54 (Universal)
VSCode Version: 1.99.3
Commit: 5c17eb2968a37f66bc6662f48d6356a100b67be0
Date: 2025-10-21T19:07:38.476Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 25.0.0

For AI issues: which model did you use?

Auto with claude-4.5-sonnet, gpt-5 and claude-4.5-haiku enabled

Additional Information

It does not look like an AI issue to me, more like the AI is smart enough to find alternative ways to edit files.

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like
2

I wonder if the problem also potentially exists with something like echo $(rm -f /path) or similar. I’ve not observed it.

3

To echo this (pun :frowning:). I had to remove a different shell comment as the agent was using it to apply patches via the shell instead of using the in-IDE edit tools. I wish I could remember which one, but it was a fairly standard shell comment that it was using to forward patches to the file…maybe a git command? Sorry I can not recall.

4

Any comment from the developers on that problem? Is there a simple workaround (other than banning Allowlists from your workflow?)

5

Hey, thanks for the report. This is a clear security issue, allowlisted commands shouldn’t bypass file edit confirmation via redirects.

I’ll pass this to the team. The expected behavior you described (treating echo >> file as a file edit requiring confirmation) makes sense as a safety guardrail.

As a temporary workaround, you can:

  • Remove echo from the allowlist (temporarily keep only read‑only commands like grep)
  • Keep config files under version control (as you’re already doing)

We’ll track this for a fix. Thanks for catching it.