Goose (Block)

Anyone researching goose today will hit stale information, including on this page's submitted URL.

Block donated goose to the Agentic AI Foundation (AAIF), a new Linux Foundation body announced 9 December 2025, alongside Anthropic's Model Context Protocol and OpenAI's AGENTS.md. AAIF platinum members are listed as AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI.

On 7 April 2026 the project moved its infrastructure to match: the GitHub repository relocated from block/goose to aaif-goose/goose, and documentation from block.github.io/goose to goose-docs.ai. The old docs URL now serves only a redirect stub. The project's own post frames this as continuity — "the project, the community, the mission — remains the same" — and does not set out a new governance structure, steering committee, or a statement of what formal role Block retains. That detail is not established from public sources.

Practical consequence for a buyer: most third-party comparisons, star counts and reviews you will find were written against block/goose and are out of date on ownership, and often on numbers. Treat anything citing "27k stars" or "Block's agent" as pre-2026.

goose is a native agent that runs on your own machine — desktop app for macOS, Linux and Windows, plus a CLI and an API — written in Rust. It is model-agnostic by design and Apache-2.0 licensed.

The strengths that are real and worth paying attention to:

It is not a coding agent. The project positions it as "a general-purpose AI agent that runs on your machine. Not just for code — use it for research, writing, automation, data analysis." This is the clearest thing separating goose from Claude Code, Cursor or Aider, and it is borne out by how Block describes its own internal use (see below): marketing, finance and support teams, not just engineers.

No lock-in to a model vendor. The project claims support for 15+ providers including Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure and Bedrock. The Ollama path matters more than it sounds: it means there is a configuration in which no code, prompt or context leaves your network, and marginal cost is electricity. If you are in an environment where source cannot go to a third-party API, that is a short list of options and goose is on it.

Recipes are a genuinely uncommon primitive. A recipe is a YAML file packaging "extensions, prompts, and settings together" so a working session setup can be handed to a colleague and launched directly. Subrecipes let one recipe delegate to parallel subagents. Most agent tools make you re-explain your setup in prose each time; goose lets you version-control it. If you have a workflow several people repeat, this is the feature to evaluate first.

It is very actively maintained. v1.46.0 shipped 12 August 2026, with v1.40–v1.45 all landing between 2 July and 29 July 2026 — roughly weekly cadence. 52,751 GitHub stars and roughly 6.0k forks as of 13 August 2026. This is not a project at risk of going quiet.

This is the part of goose that most deserves a careful read, and the documentation is unusually candid about it. Three separate mechanisms, and none of the two protective ones are on by default.

Permission mode defaults to fully autonomous. goose documents four modes — Completely Autonomous, Smart Approval, Manual Approval, Chat Only — and states plainly: "Autonomous Mode is applied by default." Out of the box, goose will modify and delete files and run shell commands without asking. Smart Approval uses an LLM-based classifier ("PermissionJudge") to auto-approve only what it assesses as safe; Manual Approval asks every time. Changing this is one config setting (GOOSE_MODE, or /mode mid-session), but you have to know to do it.

Prompt injection detection is opt-in. It works by intercepting tool calls, extracting parameter text, matching against threat patterns and pausing above a confidence threshold; an ML-based classifier endpoint can be substituted for the default pattern matching. The docs state the limitation themselves: "These checks provide a safeguard, not a guarantee. They detect known patterns but cannot catch all possible threats, especially novel or sophisticated attacks."

Adversary mode is opt-in and fails open. This is the more interesting design — a second agent instance reviews each shell or automation-script tool call against your original task and returns ALLOW or BLOCK. It is enabled by creating ~/.config/goose/adversary.md; delete the file to disable. It uses the same model and provider goose is already configured with, so it adds model calls to every reviewed tool call — the docs do not quantify the token or latency overhead, and neither can we. Critically, the docs state: "If the reviewer fails for any reason, the tool call is allowed through (fail-open)." Read that as: adversary mode raises the cost of an attack, it does not gate execution.

The project's own SECURITY.md is direct about the residual risk: goose "may follow commands found embedded in content even if those commands conflict with the task given to goose," and recommends running it in VMs or restricted-privilege containers, reviewing generated code, and only installing MCP extensions you have vetted.

None of this is disqualifying — it is the honest state of the art for agents with shell access. But it means goose is safe-by-configuration, not safe-by-default, and someone has to own that configuration before it runs against anything production-adjacent.

Veria Labs published a disclosure on 24 March 2026 describing a cross-site WebSocket hijacking flaw in goose's "goose web" feature. An unauthenticated local HTTP server combined with a wildcard CORS policy (Access-Control-Allow-Origin: *) meant any website a user visited while goose web was running could talk to the local goose server and, through goose's enabled tools, achieve remote code execution with no user interaction.

The response is the part worth weighing. Reported 22 November 2025; fixed 23 November 2025 — the team replaced the wildcard CORS policy with restricted origins and added a ws_token requirement for WebSocket connections. The affected feature was subsequently removed entirely in PR #7696, in v1.25.0 (March 2026). No CVE is mentioned in the disclosure.

A ~24-hour turnaround on a critical unauthenticated RCE, followed by removing the risky surface rather than just patching it, is a better signal about this project than the existence of the bug is a bad one. Vulnerability disclosure goes through the repository's Security tab, escalating to [email protected].

There is no licence fee and no seat price — Apache-2.0. We could not establish that any commercial support tier, paid edition, or SLA offering exists for goose from AAIF, Block or a third party; treat that as "not established" rather than "confirmed absent", but plan on community support via GitHub Issues and Discord.

Your actual costs are:

1. Model tokens, billed by whichever provider you configure. goose does not bundle inference. This is the whole cost line for cloud models, and it is unbounded — an autonomous agent decides how many calls to make. Budget alerting and rate-limit handling are your problem, not the tool's. If you turn on adversary mode, add roughly one extra review call per shell tool call on top.
2. Zero, if you run Ollama locally. This is a genuine and unusual option at this maturity level.
3. Configuration and operational time. Choosing a model, wiring MCP extensions, setting permission mode, writing recipes.

We deliberately are not repeating the per-month dollar figures that circulate in comparison articles ($5–20/month for solo use, and similar). None of them cite a measurement methodology and goose's token consumption relative to other harnesses is not established from any source we could find. Your spend depends on your model choice and how autonomously you run it, and you should measure it in a first week rather than trust a number.

goose does not publish SWE-bench, Terminal-Bench, or any standard agentic benchmark result, and we could not find one from an independent evaluator either. A GitHub issue (#895, opened 29 January 2025) explicitly asked the project to benchmark against Aider and OpenHands on SWE-bench; it is closed, with no published result that we could locate.

What the project publishes instead is the "goose Vibe Check" — its own framework of eight manually designed tasks across a Core suite (file creation, directory listing, search/replace) and a Vibes suite (blog summarisation, implementing Flappy Bird, webpage creation, restaurant research, data analysis), each model run three times. The project is upfront that this is not rigorous: it describes such evaluations as not "the rigorous, peer-reviewed benchmarks that research labs publish in academic papers," but as quick intuitive assessments. Its stated focus is deliberate — it emphasises "tool calling capabilities" over text generation, which is a defensible thing to optimise for in an agent harness.

The honest position for a buyer: there is no number that lets you rank goose against Claude Code or Codex on task success. Several comparison sites assert a specific SWE-bench figure for goose; none we checked cite a source or methodology, and we are not repeating them. If benchmark parity is how your organisation makes this decision, goose will not give you the input, and you will need to run your own evaluation on your own repos.

The strongest adoption evidence is Block's account of its own internal deployment, which should be read as a first-party claim rather than independent corroboration. Angie Jones, VP of Engineering for AI Tools & Enablement at Block, described on an Aviator podcast (11 December 2025) a company-wide rollout in roughly eight weeks, spreading beyond engineering to marketing, finance, product, customer service, design and executive assistants; 60+ internal MCP servers built during a single Hack Week, with "more than twice that" since; and one sprint team that "completed three weeks worth of work" in its first week using goose against Jira/Linear tickets. Jones also describes ~50 engineers spending roughly 30% of their time on AI enablement — which is worth noting as context: that rollout came with substantial dedicated staffing.

Widely repeated figures of "~60% of Block's workforce using goose weekly" trace back to Block-affiliated sources and we could not corroborate them independently.

Beyond Block, we found no independent, named enterprise deployment write-ups. That is normal for a project of this age and does not indicate a problem — but it does mean the strongest usage evidence available is from the organisation that built it.

Stated as trade-offs to weigh, not as warnings:

• You need a contract, an SLA or compliance attestations. We could not establish that any commercial support, certification (SOC 2, HIPAA or otherwise), or paid tier exists. If your procurement requires a counterparty, this is a blocker regardless of technical fit.
• You want the highest measured task success and are willing to pay for it. goose's flexibility is real, but it is a harness; output quality tracks the model you point it at, and there is no published benchmark to show its harness adds a measurable edge. Buyers optimising for peak coding accuracy on a single vendor's models should evaluate that vendor's own agent alongside it.
• Your team is not comfortable in a terminal and config files. There is a desktop app, but recipes, MCP extension configuration and permission modes live in YAML and environment variables.
• You want a settled, stable target. Weekly releases and a governance transition in the last eight months are both signs of health, but they also mean documentation, repo URLs and internal structure have moved recently and may move again.
• You need governance certainty today. The AAIF move plausibly reduces single-vendor abandonment risk — that is the point of donating to a foundation — but the concrete governance structure, maintainer authority and Block's ongoing formal role are not established from published sources yet.