Back to Blog

Why Your AI Agent Keeps Asking Permission

April 9, 20264 min readBy EnvHaven Team

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.

ToolMechanism
Claude Codesettings.json with bypass permissions mode
Codexconfig.toml with no-approval, full-access mode
OpenCodeOPENCODE_PERMISSION environment variable
fxFX_PERMISSION_MODE environment variable
Antigravity CLIExecutable launcher that adds --dangerously-skip-permissions
Grok BuildExecutable launcher that adds --always-approve
Kimi Code CLIExecutable launcher that adds --auto
Muse CodeExecutable 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.

ToolHow to re-enable prompts
Claude CodeRemove defaultMode from ~/.claude/settings.json
CodexEdit or remove ~/.codex/config.toml
OpenCodeunset OPENCODE_PERMISSION
fxexport FX_PERMISSION_MODE=ask
Antigravity CLIRun /opt/envhaven/bin/agy, the tool itself without its launcher
Grok BuildRun /opt/envhaven/bin/grok
Kimi Code CLIRun /opt/envhaven/bin/kimi
Muse Codemuse --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.