Blog
Goose GOOSE_MODE=auto: the agent that starts in yolo mode
Most agents make you ask for yolo mode. Goose makes you ask to leave it. That inverts every piece of advice written for the other tools.
Goose runs in auto mode by default, which approves every tool call without asking. Change it with GOOSE_MODE, /mode or goose configure: approve asks before anything that writes, smart_approve asks based on risk, and chat uses no tools at all. Goose has no sandbox, so in its default mode nothing sits between a tool call and your machine. Forkbench adds a wall and keeps keys out of reach: a key used through Vault never enters Goose's environment.
The default is the dangerous one
Goose's documentation states it plainly: autonomous mode is applied by default. In the source, auto mode approves every tool before any other check runs, and logs that all tools were approved.
Goose was started at Block and is now maintained under the Linux Foundation's Agentic AI Foundation, with its repository at aaif-goose/goose. The default has not changed through the move.
The four modes
GOOSE_MODE takes four values, set as an environment variable, in config.yaml, through goose configure, or with /mode in a session.
- auto. Never asks. The default.
- smart_approve. Asks based on the risk of the action, and remembers approvals per tool.
- approve. Asks before every tool that writes; reads still run on their own.
- chat. Uses no tools, for conversation and analysis only.
Nothing underneath
Goose has no sandbox. The only isolation-related code in it exists to step out of Flatpak packaging so it can run commands on the host, which is the opposite direction.
Two inspectors exist and neither changes this. Prompt-injection detection is off by default, and the egress inspector logs network requests without blocking them. Per-tool overrides, Always Allow, Ask Before and Never Allow, are the real control you have, and Never Allow on the tools you would not want run unattended is the first thing worth setting.
How this works in Forkbench
Forkbench is a desktop app for running coding agents. Goose runs in it as the goose command you installed, with your config.yaml untouched, and reaches the Thread's notes and board through the fb command on its PATH.
Because Goose starts unprompted and unsandboxed, what Forkbench adds counts for more here than for most agents. A Thread can be locked to a set of folders by the kernel, inherited by every process Goose starts, which is the only wall a default Goose session will have. And a key in Vault is used by the command that needs it without the value entering Goose's environment, so the default mode has no token to spend.
The limit: the folder lock does not filter network traffic, and Goose's egress inspector only logs. Keeping the key out of the process is the part that holds regardless.
Related: Yolo mode in every coding agent, compared, Claude Code: what --dangerously-skip-permissions actually skips, How to sandbox an AI coding agent on macOS
Frequently asked
What is Goose's default permission mode?
auto, which approves every tool call without asking. Goose's documentation states that autonomous mode is applied by default.
How do I make Goose ask before running tools?
Set GOOSE_MODE=approve, or smart_approve for risk-based prompts, as an environment variable, in config.yaml, through goose configure, or with /mode in a session. Per-tool overrides can also force a prompt or refuse a tool outright.
Does Goose have a sandbox?
No. Goose runs tools directly on your machine with your user's permissions, in every mode. Bounding it means adding a boundary from outside, such as a folder lock or a container.
Where is the Goose repository now?
At github.com/aaif-goose/goose, after Block donated the project to the Linux Foundation's Agentic AI Foundation. Documentation lives at goose-docs.ai.