Goose CLI Review: Block’s Open-Source Agent After the Linux Foundation Handoff

The first thing worth saying about Goose is that it is not trying to sell you a model. Most of the AI coding agents that matter in mid-2026 are funnels — the agent is good, and it happens to route you toward the vendor’s own frontier model and the vendor’s own subscription. Goose, the open-source agent Block has been building in the open, inverts that. It is a host: you bring the model, you bring the tools, and Goose orchestrates them on your machine. When Block handed governance of the project to the Linux Foundation — which we covered as news on this site — that posture stopped being a marketing claim and became a structural fact. Nobody owns the steering wheel anymore.

I ran Goose for a couple of weeks on an M2 MacBook Air, mostly in the CLI, against a real TypeScript codebase and a pile of one-off shell-and-file chores. What follows is the hands-on take: what the daily workflow actually feels like, where the MCP extension model pays off, where the rough edges are, and how it compares to the two terminal agents most people will be choosing between — Claude Code and OpenCode. I went in skeptical of “vendor-neutral” as a feature. I came out thinking it is the most interesting thing about the tool, with caveats.

Provider-agnostic by design, not by bolt-on

Goose treats the model as a configuration choice, and it means it. On first run, goose configure walks you through picking a provider and a model — Anthropic, OpenAI, Google, an OpenAI-compatible endpoint, a local Ollama runtime, whatever you have keys for. That sounds like a checkbox feature until you actually live with it. I started on a Claude model for the heavy reasoning work, then dropped to a cheaper model for grunt tasks like renaming things across files, then pointed it at a local model on an afternoon when I wanted to keep a sensitive repo entirely off the network. Same agent, same muscle memory, three different brains behind it.

This is the part of the local-first/privacy posture that I think gets undersold. “Local-first” with Goose does not only mean the agent runs on your machine and reads your files directly rather than uploading a project to someone’s cloud — though it does mean that, and that alone matters for regulated work. It also means you can choose how much leaves the machine at all. Run it against a local model and the loop never touches an external API. Run it against a hosted model and only the context you send goes out, on credentials you control, with no intermediary subscription deciding your rate limits or retaining your prompts under terms you did not negotiate.

The honest trade-off: Goose is only as good as the model you feed it. There is no house model quietly tuned to make the agent shine. Point it at a weak model and you get a weak agent with a nice CLI. The provider-agnostic design hands you the responsibility for output quality, and on a frontier model the results were genuinely strong — multi-file edits, sensible tool use, decent recovery when a command failed. On a small local model, it was fine for mechanical edits and visibly out of its depth on anything requiring real reasoning. That is not Goose’s fault, but it is Goose’s reality, and it is the opposite of how a single-vendor agent feels, where the model and the harness are co-tuned.

The MCP extension ecosystem is the real engine

Goose’s capabilities come from extensions, and extensions are built on the Model Context Protocol. This is the architectural bet that makes the whole thing cohere. Instead of a fixed, bespoke set of built-in tools, Goose speaks MCP, so any MCP server — for filesystem access, a database, GitHub, a browser, an internal company API — becomes a capability you can attach. There is a built-in developer extension that gives the agent shell and file editing out of the box, and from there you bolt on whatever the task needs.

In practice this felt like the right abstraction. When I wanted Goose to touch a Postgres instance, I did not wait for Block to ship a Postgres feature — I attached an existing MCP server and the agent could query. Because MCP is an open standard rather than a Goose-specific plugin format, the same servers work across other MCP-aware tools, so the ecosystem is not a walled garden you are investing in at your own risk. That is a meaningful difference from agent platforms whose “plugins” only ever work inside that one product.

The rough edges show up here too. Extension discovery is not as polished as a curated app store; you are often reading a README to learn what an MCP server expects, what environment variables it needs, and how to wire it into Goose’s config. A misconfigured extension fails in ways that are not always self-explanatory, and I burned time more than once on an extension that silently did nothing because a key was missing. The power is real, but the on-ramp assumes you are comfortable reading docs and editing config, not clicking through a wizard.

Living in the CLI: sessions and recipes

The terminal workflow is built around sessions. You start a session, describe what you want in natural language, and Goose plans, runs tools, edits files, and runs commands, narrating as it goes and pausing for confirmation on actions that change things. Sessions persist, so you can resume a named session later and keep the accumulated context rather than restarting cold. After a few days this felt natural — close to how Claude Code and OpenCode operate, which is to say the terminal-agent interaction model has largely converged.

The feature that distinguishes the day-to-day is recipes. A recipe is a reusable, parameterized definition of a task — a saved prompt-plus-configuration you can run repeatedly or hand to a teammate. Where a session is a conversation, a recipe is a repeatable procedure. I turned a fiddly multi-step chore (regenerate fixtures, run a specific test subset, summarize failures) into a recipe and stopped re-explaining it every time. For teams, recipes are the mechanism that turns one engineer’s clever agent workflow into something the whole team can run identically, which is exactly the kind of thing that usually gets lost in chat history.

A grounded note on what the CLI does not yet feel like: it is not the frictionless, deeply-tuned experience that a vendor pouring resources into a single product can deliver. Output formatting, the polish of confirmation prompts, and the speed of the inner loop all sit a notch below the most refined commercial agents. There is also a desktop app alongside the CLI if you want a GUI, but the CLI is where Goose feels most at home and most powerful.

How Goose compares to Claude Code and OpenCode

The terminal-agent field has settled into a few credible options, and the choice between them is less about raw capability than about what you are optimizing for. Claude Code is the polished, single-vendor experience — tightly tuned to Anthropic’s models, smooth out of the box, and the one I would hand to someone who wants the best inner-loop feel with the least setup. The trade is that you are inside one vendor’s ecosystem by design.

OpenCode is the closest philosophical cousin to Goose: an open-source terminal agent that is provider-agnostic and aims to work with many models. The practical difference I felt is one of architecture and lineage. Goose’s organizing principle is MCP extensions plus the recipe abstraction, and its governance now sits with a neutral foundation rather than a company. OpenCode is a strong, fast-moving open project in its own right; if you want an open terminal agent, both deserve a look, and which one fits depends on whether the MCP-centric extension model and the foundation-backed neutrality matter to you specifically.

The differences in model strategy and governance are the load-bearing ones. If your decision criterion is “best experience today,” lineage and licensing barely matter and Claude Code is hard to beat. If your criterion is “what can I commit a team to for years without betting on one company’s continued goodwill,” the calculus flips, and Goose’s neutrality becomes the feature you are actually buying.

Who should run Goose

Run Goose if vendor neutrality is a real constraint, not a preference. Teams in regulated industries, shops with strict data-handling rules, and engineering orgs that have been burned by a tool’s pricing or licensing changing under them are the natural audience. The local-first posture and the ability to run entirely against a local model make it credible for work that cannot leave the building, and the Linux Foundation governance is a genuine answer to the “what happens when the vendor changes the deal” question that single-vendor agents cannot match.

Run Goose if you already live in the MCP ecosystem or want to. The extension model rewards people comfortable assembling their own toolchain from MCP servers and willing to read a README to wire things up. Recipes make it especially worthwhile for teams that want to standardize agent workflows rather than have each engineer reinvent them.

Skip Goose, or at least start elsewhere, if you want the most frictionless possible experience with zero assembly. If you are a solo developer who just wants a great agent in the terminal tonight and does not care about lock-in, a co-tuned single-vendor tool will feel smoother on day one. And remember the core caveat throughout: Goose’s output quality is the quality of the model you point it at. The harness is excellent; it does not manufacture intelligence the underlying model lacks. Choose the model deliberately, and Goose rewards you with control that the polished alternatives structurally cannot offer.

FAQ