Why Your AI Agent Keeps Asking Permission
Every AI coding tool ships with its own permission system.
Claude Code asks before writing files. Codex requires explicit approval for each action, and OpenCode gates file modifications. Antigravity CLI also pauses for permission by default. Each tool independently decided that agents need guardrails.
On your laptop, that caution is warranted.
The mismatch
When an agent runs on your local machine, permission prompts serve a real purpose. Your SSH keys are on that filesystem. Your browser cookies, your Git credentials, your cloud access tokens. An unrestricted agent in your home directory has access to everything you do.
So each tool adds its own safety layer. Different tools, different mechanisms, same idea: require human approval before acting.
In a container, the isolation is structural. The filesystem contains only what you put there. There are no personal credentials beyond what you’ve explicitly provided, nothing that can’t be recreated in seconds. The walls exist at the infrastructure level. Permission prompts inside that container add friction without adding security.
What we changed
As of today, EnvHaven pre-configures every AI coding tool with full access by default. Not via flags you remember to pass each session, but as part of how the environment initializes.
| Tool | Mechanism |
|---|---|
| Claude Code | settings.json with bypass permissions mode |
| Codex | config.toml with no-approval, full-access mode |
| OpenCode | OPENCODE_PERMISSION environment variable |
| fx | FX_PERMISSION_MODE environment variable |
| Antigravity CLI | Executable launcher that adds --dangerously-skip-permissions |
| Grok Build | Executable launcher that adds --always-approve |
| Kimi Code CLI | Executable launcher that adds --auto |
| Muse Code | Executable launcher that adds --disable-approval to a bare muse, keeping its sandbox |
The configuration runs during the container’s s6 init sequence, before you open a terminal. Tools that use config files (Claude Code, Codex) get defaults copied with a no-clobber approach: if you’ve already customized your settings, they’re left alone. Tools that use environment variables (OpenCode, fx) have the vars set in the image itself. Antigravity CLI, Grok Build, Kimi Code CLI, and Muse Code take a flag instead, so each one starts through a small launcher in the image that adds it, in scripts as well as in an interactive terminal.
When you open a terminal and run any of these tools, they just work. No “approve this file write?” dialogs. No “confirm command execution?” gates. The agent runs, you review the output.
Why not just pass flags?
You could configure each tool yourself. Run claude --dangerously-skip-permissions. Edit Codex’s config file. Set the env vars manually. We wrote about this approach for Claude Code specifically.
It works, but it’s per-session and per-tool. Every new terminal means re-entering flags or remembering which config goes where. The friction compounds when you switch between tools throughout the day, and it resets every time you spin up a fresh workspace.
Infrastructure-level configuration means the defaults are right from the start. Set once, applied everywhere, surviving container restarts.
Re-enabling prompts
Everything is reversible.
| Tool | How to re-enable prompts |
|---|---|
| Claude Code | Remove defaultMode from ~/.claude/settings.json |
| Codex | Edit or remove ~/.codex/config.toml |
| OpenCode | unset OPENCODE_PERMISSION |
| fx | export FX_PERMISSION_MODE=ask |
| Antigravity CLI | Run /opt/envhaven/bin/agy, the tool itself without its launcher |
| Grok Build | Run /opt/envhaven/bin/grok |
| Kimi Code CLI | Run /opt/envhaven/bin/kimi |
| Muse Code | muse --approval-mode on-request |
The remaining tools (Goose, Amp, Kiro, and others) either have no permission system or auto-approve by default.
The honest caveats
This is the right default for isolated containers. It is not universally correct.
If you mount personal files into the container, the isolation assumption breaks. The permissions exist for a reason; they’re just redundant when the environment is disposable. Don’t bypass them in contexts where they’d actually protect something.
If you share a workspace and want to prevent accidental modifications to shared state, re-enabling prompts for specific tools is straightforward. The no-clobber design means your custom settings persist across container restarts.
None of this changes what the models can do. An agent with full permissions can still write bad code, install conflicting packages, or break your build. The difference is speed: it breaks things quickly instead of asking permission first. That tradeoff works when the environment is cheap to recreate. It would be a totally different tradeoff on a machine you care about.
Why this matters
The trend in AI tooling is toward more autonomy. Agents that plan multi-step tasks, execute them end to end, and iterate on failures without human input at each step. Permission prompts interrupt that loop.
Every tool vendor knows this. Claude Code has --dangerously-skip-permissions. Codex offers a danger-full-access mode. These flags exist because the vendors understand their own safety rails get in the way. But making “no rails” the default would be irresponsible when most users run the tools locally.
A container environment can make that choice. The isolation is architectural, not configurable. Full access becomes the sensible default when there’s nothing personal to damage.
EnvHaven is MIT-licensed. Self-host it or use managed hosting.
Related Articles
Custom Domains: Add a CNAME, We Handle the Rest
Point your own domain at an EnvHaven workspace with a single DNS record. SSL is automatic. No special account required.
Three Tiers, Docker, and What Changed
Existing subscriptions are now Hobby. Plus and Pro add more resources and Docker access inside workspaces. Here's what changed and why.
Your Tools, Your Keys, Your Models
The major AI coding tools, built-in. Authenticate with your own API keys and talk directly to the providers. Nothing is proprietary.