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
Add echo to the Allowlist
Ask about something that could be fixed by adding something to a configuration file
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.
To echo this (pun ). 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.
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.
@deanrie I think it was cat that was used to do this as well. I’ll re-add it to my settings and see if it happens again. I can’t think off the top of my head how this command would be used to make a patch to apply, but there is no other reason I would have taken it away as it is really nice allowing the agent to use cat.
Not to be pedantic, but I’m pretty sure that echois a read-only command, as far as the file system is concerned. Moreover, I can probably get grep to do anything that I could get echo to do (e.g., grep ‘.*’ <<< “Look at me echo!”).
So, I think the problem is the redirection, not the source command.
Perhaps adding some “guidance” to the prompt (like what files/directories may or may not be modified) would help?
Thanks @deanrie for passing that to the team. Indeed, I agree with @webbnh that the problem is specifically the redirection and not the command. If the agent is capable of doing this with echo, I see no reason it would not us any other command that has any other output to achieve the same goal. Here are a few examples I can think of:
If env is allowlisted, setting environment variables to what you want then run env >>
If grep is allowlisted, find a file that has the desired content and run grep >>
If cat is allowlisted, cat <<EOF and a redirect and you are in business
Another couple of things that comes to mind regarding allowlists:
Can the allowlist button recognize by default commands that have subcommands, and allowlist only the specific subcommand when you click on the button? For example, I manually added tmux capture-pane to the allowlist, but not tmux send-key. By default, if I click on the allowlist button, it allows all of tmux. Same obvious problem with git, where git diff might be OK but git commit is not. So if the agent suggests git log and I click on allowlist, I would like the allow list to contain git log and not git.
Same problem with options. I might be OK with sed without allowing sed -i to take a simple example. sed treats files as input, sed -i edits the files in place, so they have remarkably different filesystem semantics.
Maybe add another list of “dangerous patterns” that automatically disable the effect of allowlist when specific patterns are on the command-line. Not sure how to make that easy to use, but disabling the allowlist on things that write into /proc or /etc might be sensible…
). 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.
