Why does adding more extensions make the agent worse?

Every enabled extension puts its tool definitions into each request. That costs input tokens on every turn and spreads the model attention across a longer menu, so tool selection gets less reliable. Keep the always-on set to what the task actually needs.

Which provider option should I choose for a custom endpoint?

The generic OpenAI-compatible one rather than a named vendor. That is the choice that prompts for a host or base URL as well as a key; a vendor-specific option assumes a fixed endpoint and only asks for credentials.

Is it safe to let Goose run commands without asking?

Not on a machine with your credentials on it. If you want unattended operation, run it in a container or VM scoped to the task, keep work on a branch, and treat anything an extension fetches from the internet as untrusted data rather than instructions.

Goose Setup Guide: Providers, Extensions and Safe Defaults

Goose is an open-source agent that runs on your machine, with a command-line interface and a desktop application over the same core. It is model-agnostic and extension-driven, which makes it a good fit for a bring-your-own-endpoint setup and also means two separate configuration surfaces to get right: the provider, and the tools.

The provider half takes about two minutes. The extension half is where the interesting decisions are, because every tool you attach is present in every request whether or not the model needs it.

Configuring a provider

Goose has an interactive configuration flow — run its configure command and it walks you through choosing a provider and entering credentials, rather than making you hand-write a file first. Use that path for the initial setup; it writes the file for you in the right place and stores the secret where the platform expects it.

What you are looking for in the provider list is an OpenAI-compatible option rather than a specifically named vendor, because that is the choice that will prompt for a host or base URL in addition to a key. If you only get a key prompt, you have selected a provider whose endpoint is fixed.

Three values matter and they are the same three everywhere: the base URL, ending at the version segment of your provider path with no operation appended; the API key; and the model identifier, which is passed upstream verbatim and must match exactly what your provider publishes. Where compatibility holds and where it leaks is worth reading once in the compatibility explainer.

After the flow completes, the settings live in a configuration file under your user configuration directory. It is worth opening once to see what was written, both so you can fix it by hand later and so you can confirm the key is not sitting in plain text where you did not expect it.

Extensions are MCP servers, and they are not free

Goose calls its tool integrations extensions, and they are MCP servers — the same protocol other agents use to attach filesystem access, shell execution, issue trackers, browser control or a database. Some ship built in; others you add by pointing at a command or a remote server.

The instinct is to enable everything interesting. Resist it. Every enabled extension contributes its tool definitions to every request, which costs input tokens on each turn and, more importantly, spreads model attention over a longer menu of options. Agents get less reliable, not more capable, as the tool list grows past what the task needs.

Enable extensions per task where the interface allows it, and keep the always-on set small: file access, shell if you need it, and whatever single integration the current work depends on. If you are new to the protocol, what MCP actually is explains why the tool list ends up in the prompt at all, and tool schema design covers why a badly described tool is worse than a missing one.

Decide your approval posture before the first real task

An agent with shell access is a program that can run any command your user account can run. Goose supports modes that range from asking before every action to operating without interruption, and the choice deserves a deliberate decision rather than whatever gets you through the current task fastest.

A defensible baseline: let it read freely, review writes until you trust it on this codebase, and require confirmation for shell commands. If you want it to run unattended — and that is the point of an agent for long tasks — put it in a container or a VM with only the credentials that task needs, rather than relaxing approvals on your laptop. The reasoning is set out in agent sandboxing.

Always work on a branch. Version control is the only undo that survives a multi-file session, and it is far quicker than reconstructing what happened from a scrollback buffer.

Sessions, context and cost

Goose keeps work in sessions you can resume, which is genuinely useful and is also where cost accumulates. A resumed session carries its history forward, so every subsequent turn pays for everything that came before it until the history is compacted.

Two habits control this. Start a new session for a genuinely new task rather than continuing an old one out of convenience. And be deliberate about what you attach — pulling a large file into context because it might be relevant is the single most common reason a cheap session becomes an expensive one.

If you are running this daily, it is worth understanding where the money actually goes; agent cost control patterns covers the levers that matter in order of effect, and most of them are about context rather than model price.

Verifying the setup

Test in three steps. Ask a one-sentence question first: if it answers, the base URL, key and model name agree, which eliminates most setup failures at once.

Next, ask it to read a specific file in the repository and quote a line back. This exercises tool calling and the filesystem extension, which is a different path from chat and the step that catches a model that cannot negotiate tools.

Then give it a small real task with a verifiable outcome — make a test pass, rename a symbol across two files — and watch what it does rather than only reading the summary. The summary is generated by the same model that did the work.

What commonly goes wrong

A 401 is a key from a different provider, or trailing whitespace from a paste. A 404 on the endpoint is a duplicated version segment in the base URL. A 404 naming the model is an identifier your provider does not serve — list the models from the endpoint to settle it rather than guessing.

If the agent answers but never touches a file, the filesystem extension is not enabled or the model is not calling tools. If an extension fails to start, run its command by hand in the same shell and read the error directly; a missing runtime or a path issue is far more common than a protocol problem. And if an extension pulls in untrusted content — web pages, issues, third-party documentation — treat everything it returns as data rather than instructions, which is the whole subject of prompt injection and agent security.

The takeaway

Use the interactive configure flow, pick the OpenAI-compatible provider so you get a base URL field, and set the model identifier exactly. Then keep the always-on extension list short, require confirmation for shell commands until you have a sandbox, and start fresh sessions for new tasks. Provider setup is the easy half; the extension list is what determines whether the agent is reliable.