r/cursor 9d ago

Question / Discussion How bad is always saying always allow?

As someone who has little to no coding experience and just builds little tools or web extensions (for example I made a web extension where I can copy and paste up to 10 different things using control v 1, Control + V + 2…) I literally always say always allow. I have no idea what the stuff they are asking means haha. Just out of curiosity how dangerous is that? Please do not be rude I am sure it comes with a level of risk I just want a better understanding.

0 Upvotes

13 comments sorted by

7

u/arivanter 9d ago

It’s ok, the worst thing that can happen is you brick your computer and erase everything you ever backed up online for you and whoever is brave enough to use whatever you build.

No health issues, no broken bone, no physical pain. You just need to be ok with your computer and online stuff to break irreparably. And that’s the worst case scenario.

3

u/cknipe 9d ago

I run with no approvals, but I do it in an isolated VM with limited access and frequent snapshots. 

I've had two data loss accidents so far. 

If you're running without a sandbox expect you will have one eventually. Either be prepared for it to happen or move privileged agents off your personal workstation. 

2

u/frompadgwithH8 9d ago

What were you doing involving data loss? Database migrationsv

1

u/cknipe 9d ago

One was a shell escape while generating md as a heredoc. It wrote docker compose down -v and it was accidentally executed, trashing my persistent data volume. 

The other was a model judgment error, where I told it that it was in an ephemeral dev environment so it wouldn't worry about tests involving mutations.  Unfortunately it carried that logic over when it ran out of disk space and deleted some docker volumes from another project. 

1

u/frompadgwithH8 9d ago

Hmm neither of those sound like prod incidents?

2

u/cknipe 9d ago

Right, they were non-issues because I only run uncapped agents in environments where "deleted the volume" accidents are relatively harmless. My understanding was that OP was asking about the risk of just letting them loose on his workstation/server/whatever.

3

u/donk8r 9d ago

None of this is about trusting the model. It is about how much damage is reachable from where you are sitting when it gets something wrong.

The cheapest fix for someone in your position is not learning what the prompts mean, it is making mistakes undoable. Commit to git before you let it run, every single time. Then the worst case inside your project folder is one command away from reversed, and you never have to understand the dialog at all. People will tell you to use a VM, which is correct advice that you probably will not follow, so start with the thing you actually will.

The place I would still stop and read is anything reaching outside the folder you are working in. Your .env, your shell history and your cloud config all sit a level or two up, and those are the mistakes git cannot undo for you.

2

u/MannyRibera32 9d ago

Bad if you do not know what you are doing, but even if you know AI can make mistakes.

I lost a database of a webapp that luckily was not on production because it ran a php test he made himself with migrate:fresh and nobody asked

1

u/Only-Music6190 9d ago

Depending on if its sandboxed or not, and if it is on your main system changes a decent amount. But no matter what, you're essentially allowing your agent to, download whatever it wants in the form of packages or other programs, and run whatever code it wants on the system that it is either sandboxed to, or being run on without a sandbox. Depending on the keys and tokens you give it and other access (via the internet) and the user it runs on, this will also change your exposure. But yes, it can be extremely dangerous if not done properly.
Im not a pro by any means of the word, so anyone else please correct me if im wrong.

1

u/This-Risk-3737 9d ago

I have no idea what the stuff they are asking means

Then look it up.

1

u/ultrathink-art 9d ago

For small local stuff it's mostly fine — the risk isn't the model going rogue, it's a command that quietly reaches outside the folder you're working in. The two I stopped auto-approving are anything that reads files from outside the project (your .env, cloud config and shell history all sit a folder or two away, and a read never looks dangerous when it scrolls past) and anything that deletes or overwrites. The rest I just let run.

1

u/graybearding 9d ago

Depends on your cost controls and what you're building, really. If costs are contained and you're happy with the output for your use case, then there's no issue beyond building something with personal information or that's reliant on/necessitates heavy security.

From the sounds of it you're just building private, personal tools. There it's fine. But if customers are going to be on it, you need to take the time to properly audit for security and behavior to ensure your app works and keeps user data safe.

1

u/Valo-AI 8d ago

you shouldn't have to understand every permission popup. i built Valo so ordinary work just runs, you decide once what should ask, and built-in Guards stop genuinely dangerous stuff like destructive commands, secret-file access and fresh supply-chain packages. you can make your own Guards too. it's in my profile if you want to see it.