Hey everyone, just had a wild experience with the new 'agent' mode in Cursor. I was testing it out on a Friday evening, trying to automate some AWS ECS task definition updates with Terraform, and it literally took over my entire terminal session! 😅
I asked it to refactor a module to use `for_each` instead of `count`, and it went into this autonomous loop. It started running `terraform plan`, then `terraform fmt`, then it tried to run a custom validation script I had in a pre-commit hook. The terminal just kept scrolling with its activity, and my prompt was gone for a good two minutes. I had to open another terminal and `pkill` the process.
Has anyone else tried this feature yet? I'm super intrigued by the potential for automation, but also a bit wary now. My setup was:
- A fairly standard Terraform project structure.
- Asking the agent to "improve this terraform module for better state management."
- It was running in my project root.
I'm wondering if there's a way to scope its permissions or give it a sandbox? The idea of an AI agent that can execute commands is powerful for ops work (imagine it applying patches or scaling infrastructure!), but it needs guardrails.
What's been your experience? Any tips on using it safely, or is it still too experimental for real cloud automation tasks?
~CloudOps
Infrastructure as code is the only way
Oh man, that's a classic Friday night experiment right there! I've been tinkering with the agent mode on smaller refactors, like moving a Python function from one module to another. It's impressive, but I can see how it'd go off the rails with something as state-heavy as Terraform.
> wondering if there's a way to scope its permissions
I really hope they add some configurable boundaries, maybe a `.cursoragentignore` file or a flag that limits it to read-only operations. Letting it run `terraform plan` seems okay, but auto-running fmt and your pre-commit hook is definitely overreach.
It makes me think we'll need to develop a new habit: never start an agent from the project root. Always `cd` into a temp subdirectory first. What do you think?
Prompt engineering is the new debugging
I think the temp directory habit is a smart workaround, but it's a band-aid. The real issue is that the agent needs to understand the concept of a "dry run" or a sandboxed execution environment, especially for IaC.
Your point about configurable boundaries is key. It shouldn't just be about read-only vs. write; it's about command whitelisting. For a Terraform project, I'd want to explicitly allow `terraform fmt -check` but never allow it to run `terraform apply` autonomously, even with a `-target`.
This is a problem we've solved with other automation tools - the agent should require explicit confirmation before stepping outside a predefined "safe" command set, like git operations or linters.
Integrate or die
Called it. Yet another tool released with zero safety gates.
> it needs guardrails
It needed them before the public beta, not as a feature request after it wrecks someone's project. Your pre-commit hook example is exactly why. It's blindly executing anything it finds.
Until they publish a real security model, assume the agent can and will run any command it guesses might be relevant. Treat it like an unsupervised intern with sudo.
The temp directory trick is smart for immediate safety, but it kind of defeats the whole point for me. The agent needs the full context of the project to actually be useful - it can't refactor imports or update references if it's stuck in a sandbox.
Your idea of a `.cursoragentignore` file is gold. It reminds me of how some linters have a `--fix-dry-run` flag. A config where you could whitelist specific commands (`terraform fmt`, `go mod tidy`) but blacklist others (`terraform apply`, `rm -rf`) would be the sweet spot.
I've been burned by similar overreach with other "AI helpers" in my shell, so now I just run the agent from a separate terminal window entirely. That way I can watch its every move without losing my actual workspace. Feels like we're all just inventing our own guardrails until they build proper ones in.
You're right that the sandbox defeats the purpose, but I think we're missing the bigger question: why does any tool need to execute commands autonomously?
This feels like a solution hunting for a problem we already solved. Our CI/CD pipelines have explicit stages and permissions. Our linters have dry-run flags. We already built the guardrails. Now we're just letting an LLM pretend it's a CI server inside our terminal.
A config file is a band-aid on a bad workflow. The real fix is for the agent to suggest commands and let me, the human who understands the state of my Friday-night project, press 'Enter'.
Yeah, that's exactly the scenario I'm worried about. The idea of an agent applying patches or scaling infra is cool, but I'm stuck on the permissions model.
> I'm wondering if there's a way to scope its permissions
Have you looked at how other CLI tools handle this? Like, could it adopt a model similar to a linter where you have to explicitly pass a `--allow-execute` flag? Or maybe a session-level permission prompt?
My gut says the first useful version will be "read-only agent" or "suggest-only mode". I'd probably try it then. Would you?