Goose: Advanced features

This is page 7 of 8 for Goose. It covers six power features for after the playbook feels routine, and each one comes with what it is for, the documented way to turn it on, and what you trade for it.

None of these are needed for the jobs in this guide. Try one at a time, and keep Manual Approval on while you learn it.

Tool permissions

What it is for. Manual Approval sets one rule for every tool, but tool permissions let you set a rule for each tool on its own. Each tool can be Always Allow, Ask Before, or Never Allow, and the docs suggest Never Allow for things like deleting resources or reading credentials.

How to turn it on. Open the sidebar, click Settings, then Chat. Under Mode, click the button next to your selected Manual or Smart mode, click the extension you want, such as Developer, and use the dropdown next to each tool. Click Save Changes when you are done. In the terminal version, the same choice is under goose configure, then goose settings, then Tool Permission.

• You gain: fewer clicks for tools you trust, such as reading files, and a hard no for tools you never want a job to use.
• You risk: Always Allow on the shell tool or the text editor means writes and commands go through with no question, on your real files.
• Makes sense when: you use it to make Goose stricter, such as Ask Before on every Developer tool, or when you loosen only read-only tools and keep the shell and the editor on Ask Before.

More extensions

What it is for. Extensions are MCP servers that connect Goose to other apps and services, and the docs list more than 70 of them. Goose also checks outside extensions for known malware before it turns them on. For how skills and MCP compare across agents, and how to choose safe ones, see Skills and MCP.

How to turn it on. Open the sidebar and click Extensions. Built-in extensions have a switch, and for any other one, click Add custom extension, fill in the details the extension's own page gives you, and click Add. The docs say Goose works best with fewer than 25 tools turned on in total, so turn off what you are not using.

• You gain: new kinds of jobs, such as reading a service you use or working with a database.
• You risk: every extension can act as you, and one that reads email, messages, or web pages brings prompt injection straight to Goose. The malware check covers only extensions that run on your computer through npx or uvx, and the docs say extensions still install if the check service is down.
• Makes sense when: the extension comes from an official, trusted source, a job truly needs it, and it cannot send, post, or pay for you. Connecting your main email or bank account does not make sense for a beginner.

Standing instructions: hints, skills, and recipes

What it is for. Instead of repeating the same rules in every prompt, you can save them once. A .goosehints file holds rules Goose reads at the start of every chat. A skill is a saved set of steps Goose loads when a job matches it, and a recipe is a whole job you can rerun with one click.

How to turn it on. For hints in one folder, set the directory switcher to that folder, then open Settings and click Chat. Scroll to Project Hints (.goosehints), click Configure, type your rules, click Save, and start a new chat. Rules for every chat go in a .goosehints file in ~/.config/goose. A skill is a SKILL.md file in its own folder inside ~/.agents/skills/, and recipes are on the playbook page.

• You gain: safety rules that you write once, such as "Never delete a file, and always ask before you move one," and jobs that run the same way each time.
• You risk: hints are only instructions to the model, not a wall, so a model can still ignore them. Hints also add tokens to every message, and a skill or recipe you download from someone else is their instructions running as you, which can include scripts.
• Makes sense when: you wrote the rules yourself, or you read every line of a shared one before you use it. Treat a hint as a reminder on top of Manual Approval, not a replacement for it.

The terminal version and headless runs

What it is for. Goose also comes as a command-line program that shares its settings with the desktop app. Its goose run command can do a job with no chat window at all, which the docs call headless mode.

How to turn it on. On a Mac, the install guide gives this command.

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

On Windows, it gives this command for PowerShell. The install guide also covers Git Bash, and a fix if goose is not found afterward.

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/aaif-goose/goose/main/download_cli.ps1" -OutFile "download_cli.ps1";
.\download_cli.ps1

The script says "Windows ARM64 is not currently supported." To start a chat in the folder you are in, with a cap on turns, the commands page gives options such as goose session --max-turns 25, and a headless job looks like goose run --text "your instructions" --max-turns 10. The --max-tool-repetitions option stops the same tool from being called over and over with the same input.

• You gain: jobs you can start from a script or the terminal, with tighter loop limits than the desktop app shows.
• You risk: a headless run has nobody watching it, and this guide could not confirm what goose run does when it reaches an action that needs approval. A terminal command also runs with everything your account can reach.
• Makes sense when: you are comfortable in a terminal, the job only reads and writes inside its own folder, and you always set --max-turns. It does not make sense as a way to get around Manual Approval.

Extensions inside a Docker container

What it is for. Goose itself always runs on your real computer, but the --container option runs its extensions inside a Docker container instead. That puts a wall between those tools and your real files, which Goose otherwise lacks.

How to turn it on. This is terminal only. Start a container with Docker, find its name with docker ps, and run goose session --container <container_id>. The docs say each extension must already be installed inside the container, and that built-in extensions, which include Developer, need the Goose terminal program installed inside the container too. A separate docs page builds Goose itself inside Docker from its source code.

• You gain: commands and file changes from those extensions land inside the container, not on your real files.
• You risk: the setup is easy to get partly wrong, and an extension that is not inside the container fails instead of being walled off. Your key still lives on your real computer, and any folder you share into the container is your real folder.
• Makes sense when: you already use Docker and want Goose to run commands you do not fully trust. For most readers, the simpler wall is to run Goose inside a virtual machine, but this guide could not confirm official Goose steps for that.

A local model with Ollama

What it is for. A local model keeps your prompts on your computer and costs nothing per use. Goose supports Ollama, LM Studio, and several other local options.

How to turn it on. Install Ollama, download a model that supports tool calling, and start it. The docs name an older Qwen tag and say DeepSeek models do not work. Use qwen3.8:27b when the computer has room for its 18 GB file, or qwen3.5:4b on an 8 GB computer. In Goose, open Settings, click Models, then Configure Providers, and choose Ollama. Goose uses localhost:11434 unless you change OLLAMA_HOST, and it lists the models you have downloaded.

• You gain: privacy for your prompts and files, and no bill.
• You risk: a model that cannot use tools can only chat, and the docs say all extensions must then be off. A small local model is also weaker at the careful steps that safe file work needs, and if the model is not running, Goose shows an error such as error sending request for url (http://localhost:11434/v1/chat/completions).
• Makes sense when: your computer has plenty of RAM, the material is private, and you test the model on the goose-tryout folder before any real files.

Shared advanced topics

These pages cover the same ideas for every agent in this guide:

• Local models: Goose works with Ollama and LM Studio, so this explains how big a model your RAM can run.
• Mixing models: Goose can switch models in the middle of a chat and give a recipe its own model.
• Host access and unattended runs: Goose always runs on the host, and its Scheduler runs jobs with nobody watching.
• An always-on machine: schedules and the Telegram gateway only work while the computer stays on and awake.
• Subscription sign-ins: the Goose welcome screen offers a ChatGPT Subscription sign-in.
• Relays: the Goose docs suggest OpenRouter or Tetrate Agent Router for rate limits, and both pass your requests on to other companies.

Sources

Checked 14 November 2026.

• Managing tool permissions, for the three levels, the Settings path, and fewer than 25 tools.
• Goose extensions, for Add custom extension, the malware check, and the --container option.
• Goose Known Issues, for the malware check covering only npx and uvx.
• The same Known Issues page, for the Ollama error and for DeepSeek and qwen2.5.
• Providing hints, for Project Hints (.goosehints), the global file, and tokens on every request.
• Agent skills, for ~/.agents/skills/ and supporting scripts.
• Goose install guide, for the terminal install commands and shared settings.
• Goose research notes, for the Windows ARM64 message, the 70+ extensions count, and local providers.
• Goose CLI commands, for goose run, --text, --max-turns, --max-tool-repetitions, and --container.
• goose in Docker, for the container requirements and building Goose in Docker.
• Goose providers, for Ollama, OLLAMA_HOST, and tool calling.
• Multi-model configuration, for switching models in the middle of a chat.
• Reusable recipes, for a recipe naming its own provider and model.
• Handling rate limits.

Next

Next: Persona and rules.