I've been using Cursor daily for a few months. Like most of you, I started cautiously, reviewing every change, approving every command, basically babysitting the agent.

Every time I tried letting it run more autonomously, I'd get nervous. What if it messes with the wrong files? What if I come back to a broken environment?

Why Cursor's built-in protections aren't enough

Cursor has some guardrails, but when you're building anything real, you need more than file-level protections. You need a full development environment.

If your feature needs Postgres, Redis, Kafka, webhook callbacks, OAuth flows, or any third-party integration, you end up working in your main dev environment. That's exactly where letting the agent loose gets scary.

What I needed was the opposite: not tighter guardrails, but a full isolated environment. Real containers. Real databases. Real network access. A place where the agent can run the whole stack and break things without consequences.

Isolated devcontainers

Each feature I work on gets its own devcontainer. Its own Docker container, its own database, its own network. If the agent breaks something, I throw away the container and start fresh.

Cursor supports devcontainers natively (it's VS Code under the hood), so this setup works out of the box.

Here's a complete example from a Twilio voice agent project I built.

.devcontainer/devcontainer.json:

json

{
  "name": "Twilio Voice Agent",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspaces/twilio-voice-agent",

  "features": {
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/node:1": {}
  },

  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode"
      ]
    }
  },

  "postCreateCommand": "npm install",
  "forwardPorts": [3000, 5050],
  "remoteUser": "node"
}

.devcontainer/docker-compose.yml:

yaml

services:
  app:
    image: mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm
    volumes:
      - ..:/workspaces/twilio-voice-agent:cached
      - ~/.gitconfig:/home/node/.gitconfig:cached
    command: sleep infinity
    env_file:
      - ../.env
    networks:
      - devnet

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    env_file:
      - .cloudflared.env
    command: ["tunnel", "--no-autoupdate", "run", "--protocol", "http2"]
    depends_on:
      - app
    networks:
      - devnet

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: dev
      POSTGRES_DB: app_dev
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - devnet

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    networks:
      - devnet

networks:
  devnet:
    driver: bridge

volumes:
  postgres_data:

A few things to note:

• Cloudflared runs as a sidecar, exposing the environment via a tunnel. Webhooks and OAuth just work.

• Postgres and Redis are isolated to this environment. The agent can drop tables, corrupt data, whatever. It doesn't touch anything else.

• Each branch can get its own tunnel hostname so nothing collides.

Cloudflared routing

The tunnel can route different paths to different services or different ports on the same service. For this project, I had a web UI on port 3000 and a Twilio websocket endpoint on port 5050. Both needed to be publicly accessible.

In Cloudflare's dashboard, you configure the tunnel's public hostname routes:

Path Service 
/twilio/*
 
http://app:5050*
 
http://app:3000

The service names (app, postgres, redis) come from your compose file. Since everything is on the same Docker network (devnet), Cloudflared can reach any service by name.

So https://my-feature-branch.example.com/ hits the web UI, and https://my-feature-branch.example.com/twilio/websocket hits the Twilio handler. Same hostname, different ports, both publicly accessible. No port conflicts.

One gotcha: if you're building anything that needs to interact with ChatGPT (like exposing an MCP server), Cloudflare's Bot Fight Mode blocks it by default. You'll need to disable that in the Cloudflare dashboard under Security > Bots.

Secrets

For API keys and service tokens, I use a dedicated 1Password vault for AI work with credentials injected at runtime.

For destructive stuff (git push, deploy keys), I keep those behind SSH agent on my host with biometric auth. The agent can't push to main without my fingerprint.

The payoff

Now I can let Cursor's agent run on a task, walk away, and come back to either finished work or a broken container I can trash.

Agent mode only works when agent mode can't hurt you.

I packaged up the environment provisioning into BranchBox if you want a shortcut, but everything above works without it.