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 Aider waits for confirmation before running commands. OpenCode gates file modifications. Gemini CLI defaults to a cautious mode that pauses between steps. 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.

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 (Aider, OpenCode) have the vars set in the image itself.

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.

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.