Goose CLI auto-approves tool calls by default; Amp traps approvals in its own terminal

A developer who connected two coding agent CLIs, Goose and Amp, to a single tool that runs several agents says the biggest lesson had nothing to do with agent protocols — it was the approval defaults. According to a post on dev.to, Goose grants itself permission for tool calls when it is started without an explicit mode, meaning a wrapper that stays silent on permissions gets an agent that executes commands with no human sign-off.

Goose runs tools unless told otherwise

The post explains that Goose's default mode enables automatic approval of tool calls. Any harness or wrapper that launches the agent without specifying a mode therefore gets fully autonomous execution, regardless of what the person running it assumed. To close that gap, the author now sets the mode for each process in their runner rather than trusting whatever lives in a user's Goose configuration. Under that mapping, the modes named default, accept-edits and auto all route to Goose's approval mode, so every tool call prompts a person first. Automatic approval is reserved for the mode explicitly named bypass, and the per-process override leaves the user's own Goose settings untouched.

A chat-only mode that cannot read files

A second surprise in the post concerns Goose's chat-only mode: it switches off every tool, including read-only ones. Map a "plan" mode onto it and the result is an agent that can talk but cannot even open the files it is supposedly planning around — the opposite of what most people would expect from a planning mode.

Amp answers to no one but its terminal

Amp behaves very differently. Its streaming output, the post notes, offers no documented mechanism for an external process to answer an approval prompt, so approvals remain confined to the terminal where Amp itself is running. That is a structural problem for orchestrators: they can watch the agent work but cannot say yes or no to a tool call from outside. Amp's plan and don't-ask modes refuse every tool, including read-only ones, and only its bypass mode switches on automatic approval. In effect, a wrapper must choose between an agent that does nothing and an agent that does everything unattended, with no middle ground for interactive approval.

Empty directory first, integration second

The author's new routine for any agent CLI: before connecting it to anything, launch it once in an empty directory and watch what it does the first time it wants to call a tool. Two agents produced two very different answers, and in both cases the behaviour was not documented anywhere obvious, the post says. The findings came out of work on Styx, the author's tool for running multiple coding agents.

Why it matters

Agent CLIs are increasingly launched by other software — orchestrators, harnesses, CI jobs, scheduled tasks — rather than by a person sitting at a terminal. In those setups, the default approval behaviour is effectively the security boundary: if the caller does not explicitly pin a mode, the agent's factory default decides whether commands run without review. An agent that grants itself permission, combined with a prompt injection or a badly guessed instruction, becomes unattended code execution. The practical takeaway generalises well beyond Goose and Amp: treat permissions as something to verify empirically, per process, on day one — because the difference between "asks first" and "acts first" rarely appears on the first page of the documentation.