Goose

What it is and how it works

Goose is an open-source, terminal-native AI agent designed for autonomous, multi-step task execution rather than single-shot chat completion. It originated inside Block (formerly Square) as an internal engineering tool before being open-sourced and, more recently, transferred to the Agentic AI Foundation (AAIF) under the Linux Foundation — a governance move that matters more than it sounds. Foundation stewardship means the project's roadmap, licensing, and long-term maintenance no longer hinge on one company's product priorities, which is a meaningfully different risk profile than a VC-backed startup tool that could pivot or shut down.

Architecturally, Goose operates as a local agent loop: it takes a natural-language goal, plans a sequence of actions, and executes them directly against your shell, filesystem, and any connected extensions (Goose's term for tool integrations, conceptually similar to MCP servers). Unlike a chat-first coding assistant that proposes a diff and waits for you to apply it, Goose is built to run commands, edit files, install dependencies, and iterate on its own output in a loop until the task is done or it hits a wall. This makes it closer in spirit to an autonomous coding agent than a copilot — the operator sets the goal and guardrails, then Goose drives.

The model layer is fully decoupled from the agent runtime. Goose supports 25+ LLM providers, which is unusually broad for an agent framework — this includes local inference backends like Ollama, Ramalama, and Docker Model Runner, alongside the usual cloud APIs. Because the agent logic (planning, tool invocation, state tracking) lives outside the model itself, you can swap a cloud model for a local one without changing how Goose behaves structurally — though obviously the quality of planning and tool-use degrades with weaker local models, since agentic loops are far more demanding on a model's instruction-following and reasoning consistency than plain chat.

Deployment patterns

The dominant Goose deployment is a solo developer running it in a terminal alongside their normal workflow — either against a cloud model for maximum capability, or against a local Ollama instance for privacy-sensitive codebases or offline work. In this mode, Goose behaves like a scriptable pair programmer: you point it at a repo, describe a task ("add test coverage for this module," "migrate this config format"), and let it work through edits and shell commands with periodic check-ins.

A second pattern, given Goose's Apache 2.0 license and enterprise-friendly governance, is embedding it into internal developer tooling at a company — CI helper bots, internal automation scripts, or a standardized "agent layer" that different teams configure with their own extensions. Block's own origin story is essentially this: an internal tool generalized enough to open-source. Because it's fully self-hostable with no telemetry lock-in, teams with compliance requirements (finance, healthcare, government-adjacent) can run it against on-prem or air-gapped model endpoints via Ollama or Docker Model Runner without data leaving their network.

A homelab/local-first setup typically looks like: Ollama running a capable coding-oriented model (something in the 30B+ class if hardware allows, since agentic tool-calling is harder than chat), Goose configured to point at the local Ollama endpoint, and a small set of extensions enabled for the task at hand (filesystem access, git, maybe a web-fetch extension). This is the configuration this site cares most about — it's genuinely usable as a fully local agent, not just a local-model demo.

How it compares

Against Cursor, Goose is a fundamentally different product shape: Cursor is an IDE fork with tight editor integration, inline diff review, and a polished UX built around human-in-the-loop editing. Goose is terminal-first and more autonomous by default — it's closer to "give it a task and let it run" than "collaborate on this file with me." Cursor's UX is more refined, but Cursor is not open-source and is more tightly coupled to its own hosted infrastructure and model choices.

Against Continue.dev, another open-source AI coding tool, the comparison is closer. Continue is primarily an IDE extension (VS Code/JetBrains) focused on inline completion and chat-assisted editing, whereas Goose is a standalone agent runtime that isn't tied to an editor at all — it runs wherever your terminal runs, which makes it more suitable for CI pipelines, scripting, and non-editor workflows, but means you lose Continue's tight in-editor diff/accept UX.

Against Aider, probably Goose's closest philosophical peer — another terminal-native, git-aware coding agent with strong open-source roots — the differentiator is scope and provider breadth. Aider is laser-focused on the edit-commit loop for coding tasks and is widely regarded as extremely polished at that one job. Goose is broader in ambition (general multi-step task orchestration, not just code editing) and supports a wider provider matrix, but per the tool's own acknowledged cons, its UX is less refined and its extension ecosystem is thinner than more established players.

Best use cases and honest limitations

Goose is a strong fit for developers who want a scriptable, autonomous agent they can run against either cloud or fully local models without vendor lock-in, and for organizations that need Apache 2.0 licensing and Linux Foundation governance for procurement or compliance reasons. Its multi-step orchestration — real planning and iteration, not just single-turn tool calls — makes it suited to tasks like dependency upgrades, repo-wide refactors, or multi-file migrations where a chat-only assistant would require constant hand-holding.

It's a weaker choice if you want a polished, visual, IDE-integrated experience — the tool's own documented cons are honest here: less polished UX than Cursor or Continue.dev, documentation still catching up after the AAIF transfer, and a noticeably smaller MCP-style extension ecosystem than Claude Desktop. Teams that want turnkey extension marketplaces or heavy visual diff review will find Goose rougher around the edges. It's also worth noting that agentic autonomy is a double-edged sword: giving an agent shell and filesystem access to iterate unsupervised is powerful but requires the operator to actually understand what guardrails and extensions are enabled, especially when pointed at production codebases or run with elevated permissions. For solo engineers and infra-conscious teams comfortable in a terminal, Goose is a legitimate, provider-agnostic agent option; for those wanting a gentler, more visual on-ramp, Cursor or Continue.dev remain the easier starting points.

Install via npm: npm install -g @gooseai/goose or via pip: pip install goose-ai. Requires Node.js 18+ or Python 3.10+. Goose is an agentic CLI tool from Block (Square) that executes multi-step engineering tasks using LLMs. Authenticate with your provider: set ANTHROPIC_API_KEY or OPENAI_API_KEY. Run: goose run "Add a health-check endpoint to src/server.ts". Goose starts a session, reads relevant files, plans changes, and executes them — editing files, running commands, and iterating on results. It supports multiple MCP (Model Context Protocol) servers for extended capabilities: database access, API integration, browser control. Configure MCP servers in ~/.goose/config.yaml. First run downloads the tooling (~30 seconds) and begins task execution. Verify: goose run "What version of Node.js is installed?" — Goose runs node --version in a shell and reports the result. Goose is designed for UNIX-like environments (macOS, Linux, WSL2); native Windows support is limited. Time-to-first-action: ~10 seconds including model API latency. Works with Anthropic, OpenAI, and Google Gemini providers.

Best for: multi-tool orchestration tasks where the agent needs to coordinate across databases, APIs, filesystems, and code in a single workflow, MCP-server-heavy environments where you've already built tool interfaces for your infrastructure, DevOps and platform engineering tasks (check CI status, update config, deploy preview), developers comfortable with terminal-native agents who want extensibility beyond code editing. Not suited for: code-only pair programming (use Aider or Claude Code), Windows-native development (Goose targets UNIX-like environments), teams without MCP infrastructure investment (Goose's value compounds with MCP tool investment), lightweight autocomplete or chat in IDE (use Continue or GitHub Copilot).

Use Goose when you want an extensible agentic CLI tool with MCP server integration — connect to databases, APIs, filesystems, and browsers through MCP servers that Goose orchestrates. The MCP ecosystem is Goose's differentiator: you can give it read access to production databases or your calendar, and it can coordinate across them. Switch to Claude Code for a more polished terminal agent with better reasoning for complex code tasks — Goose is more about orchestration across tool interfaces. Use Aider for git-native pair programming with code-focused edits — Goose is a general agent, Aider is code-specific. Use Cline for VS Code-integrated agentic coding — Goose is terminal-native. Use Open Interpreter for an interactive Python/R/Shell agent. Goose's unique value is MCP — if you need an agent that can query your database, check your CI status, and edit code in a single workflow, Goose is the right tool.

Problem: Error: MCP server connection refused when Goose tries to use an MCP tool. Fix: The MCP server process must be running and accessible. Check ~/.goose/config.yaml for the correct server command and ensure the server binary/npm module is installed. Start MCP servers manually first to debug: run the command from config.yaml directly and verify it starts without errors. Goose launches MCP servers as child processes — any stdout noise can confuse the MCP protocol handshake. Problem: Goose makes changes without asking permission. Fix: Goose's default permission model varies by version. In ~/.goose/config.yaml, set require_approval: true to gate file writes and terminal commands. Goose's MCP tool access is controlled per-server — restrict write-access servers to read-only in config if you want consultative use. Problem: "Tool call failed: unexpected token" with local models via Ollama. Fix: Goose's tool-use format is provider-specific. When using Ollama, Goose sends tool descriptions in a format that some models (especially smaller ones) handle poorly. Use a tool-calling-aware model like Llama 3.1 8B with tool support or Mistral 7B v0.3. Verify the local model responds correctly to tool-calling prompts by testing with ollama run <model> --format json.