What Happens When Claude Code Gets Full Access
Claude Code has a flag called --dangerously-skip-permissions. It lets the agent read any file, write anywhere, and execute commands without asking. It's how agents work best, and almost nobody uses it.
The reason is obvious. It's your laptop. Your SSH keys live there. Your browser history. Your tax documents. One hallucination and your .zshrc is gone. The risk isn't theoretical.
So people deal with confirmation prompts. "Approve this file write?" Yes. "Execute this command?" Yes. "Create this directory?" Yes. Over and over. It's like pair programming with someone who asks permission to type.
The obvious solution
Run the agent somewhere that isn't your laptop.
If the environment is a container, with an isolated filesystem, isolated processes, and nothing personal on it, then full access isn't scary. It's just appropriate.
In the browser, open your workspace and run it directly in the terminal:
claude --dangerously-skip-permissions
Or from your local machine via Haven CLI:
haven connect . myproject-alice
haven claude -- --dangerously-skip-permissions
No confirmation prompts. The agent installs packages, modifies configs, creates files, runs builds. The sessions run in tmux, so they persist even if you close the browser or disconnect. If something breaks, the workspace is disposable. Spin up a fresh one in seconds.
Why not a sandbox SDK?
There are a few categories that sound similar but solve different problems.
Sandbox SDKs like Vercel Sandbox and Cloudflare Sandbox are APIs. Your application calls them, a VM spins up, runs some code, and dies. They exist so platforms can safely execute untrusted code. Building blocks for products, not places where you develop.
Ephemeral AI environments like E2B and Daytona are closer. They spin up disposable containers for agents to work in. But they're short-lived and programmatic. The environment lasts minutes or hours, not days. There's no persistence, no dotfiles, no long-running dev server. They're designed for one-shot agent tasks, not ongoing development.
Cloud dev environments like Codespaces and Gitpod are persistent, but they come with proprietary config formats and platform-specific tooling that ties your workflow to their product.
EnvHaven is a workspace you develop in. It persists. Your files are there tomorrow. Your tmux sessions keep running. Your dev server stays up. You close your laptop, open it the next day, pick up exactly where you left off. Standard Docker, standard Linux, no vendor lock-in.
What actually happened
A week of working this way. Here's what was different.
The biggest change wasn't speed, though things were faster. It was flow. Without confirmation prompts, the agent works autonomously. You describe what you want, walk away, come back to working code. Or broken code. But at least the agent tried things without stopping to ask every 10 seconds.
Setup tasks that normally take an hour of tutorial-following became single prompts. "Add Clerk auth with protected routes." The agent reads docs, installs packages, configures middleware, creates components. Not perfectly every time. Sometimes the auth wrapper needed tweaking, sometimes env vars were wrong. But the starting point was 80% there instead of 0%.
On managed hosting, the dev server gets a public URL automatically, useful for sharing work-in-progress. On self-hosted setups, you handle networking yourself, but the container is the same either way.
What doesn't work
Some things to be honest about.
The agent isn't magic. Complex architectural decisions still need a human. When Claude set up the database schema, it made reasonable choices, but "reasonable" isn't the same as "right for this specific project." You still review everything.
Heavy builds are slower in a container than on a beefy local machine. If you're compiling Rust or training models, you'll feel it. This workflow is best for web development, scripting, and projects where the bottleneck is setup and boilerplate, not raw computation.
And sometimes the agent just breaks things in weird ways — installs conflicting package versions, writes to the wrong config file. In a container this is fine; restart or recreate. On a laptop it would be a bad afternoon.
Why this matters
The AI agent tools are getting good fast. Claude Code, Cursor, Windsurf, OpenCode. They all benefit from fewer restrictions. The limiting factor isn't the model's capability. It's the environment.
Running these tools on a laptop forces a tradeoff between safety and effectiveness. A contained environment removes that tradeoff. Full access, zero risk to anything that matters.
That's what EnvHaven is. A Linux machine built on code-server and linuxserver.io, with Docker, SSH, tmux, and 12+ AI coding tools pre-installed. Containerized and isolated, but a real development environment, not a sandbox. The kind of place where --dangerously-skip-permissions is just how things work.
The source is MIT-licensed. Self-host it or use managed hosting if you don't want to deal with infrastructure.
Related Articles
Your Tools, Your Keys, Your Models
Twelve AI coding tools built-in. Authenticate with your own API keys and talk directly to the providers. Nothing is proprietary.
Who Owns Your Dev Environment?
Cloud dev environments are convenient until the vendor changes their mind. Owning your environment means your workflow survives regardless.
The Local Editor Problem
You shouldn't have to choose between your local editor and remote AI agents. Haven CLI bridges the two with bidirectional file sync.