goose: a Rust-based AI agent that runs on your machine, not in the cloud

What goose actually does, and who it is for

goose is a general-purpose AI agent that runs on your machine, not in a browser tab or a vendor's cloud. The README positions it as going beyond code suggestions: it can install software, execute commands, edit files, and run tests, all driven by an LLM. The target user is a developer or technical operator who wants an agent that can act on the local system, not just chat about it. It is also aimed at people who want to use their existing LLM subscriptions, since it supports Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, and Bedrock, among others. The project is part of the Agentic AI Foundation at the Linux Foundation, which gives it a governance structure beyond a single company. The name and the humor in the README suggest a friendly tone, but the underlying tool is serious: it can modify your filesystem and run commands, so it is not a toy.

The architecture: Rust core, MCP extensions, and ACP providers

goose is built in Rust, which the README cites for performance and portability. It ships as a desktop app for macOS, Linux, and Windows, plus a CLI and an API. The key architectural pieces are the provider layer and the extension layer. Providers are LLM backends, and goose supports 15+ of them. The README mentions ACP, which stands for Agent Client Protocol, as a way to connect to existing Claude, ChatGPT, or Gemini subscriptions. That is different from using raw API keys: ACP likely wraps those services in a standard interface, so goose does not need to implement each vendor's streaming quirks separately. Extensions are connected via the Model Context Protocol, an open standard that lets goose talk to external tools and data sources. The combination means goose is not tied to a single model or a single tool ecosystem. The desktop app, CLI, and API all share the same core, so a workflow designed in the CLI can be embedded in another application via the API.

Getting it running: installation and first steps

The README gives two installation paths. For the desktop app, you download it from the docs site for macOS, Linux, or Windows. For the CLI, the command is a curl pipe to bash: 'curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash'. That script fetches a release from GitHub and runs it. There is no mention of package managers like Homebrew or apt, and no checksum verification in the README. After installation, the quickstart is linked in the docs, but the README does not show any config keys. You will need to set up at least one provider, either by providing an API key or by using ACP to link an existing subscription. The docs cover installation, quickstart, and tutorials, so the actual configuration steps are documented elsewhere. The CUSTOM_DISTROS.md file suggests you can build your own distribution with preconfigured providers and extensions, which implies the configuration is modular and file-based, but the README does not show the file format.

Real limitations: trust, setup friction, and platform risk

goose is an agent that can execute commands and edit files. That is its strength and its danger. The README does not mention sandboxing, permission prompts, or rollback features. If the agent misinterprets an instruction, it could delete or overwrite files with no undo. The documentation has a diagnostics and reporting page and a known issues page, which suggests problems do occur. The curl pipe to bash installer is another risk: you are trusting the script and the network. The README does not provide a SHA256 checksum or an alternative verification method. Also, because goose supports many providers, each provider may have different capabilities and rate limits, so a workflow that works with Anthropic may fail with Ollama. The project is under active development, with releases every week or two (v1.46.0 on August 12, v1.47.0 on August 21, v1.48.0 on August 27). That fast cadence means features change quickly, and the API may not be stable. If you need a tool that stays frozen for a year, goose is not that.

The alternative: a single-provider, single-purpose agent

The obvious alternative is to use a vendor-specific agent, such as GitHub Copilot or a cloud-based coding assistant like Claude Code or OpenAI Codex. The difference is in scope and control. Those tools are tied to one LLM provider and often to one editor or platform. They are usually closed source, so you cannot inspect the code or modify the behavior. goose is open source under Apache-2.0, so you can audit it, fork it, and build your own distribution. The trade-off is that you take on the integration work. With a vendor agent, the provider handles model updates and tool integrations for you. With goose, you must configure providers, manage extensions, and debug failures yourself. The ACP support is an attempt to bridge that gap by letting you use your existing subscription, but it still requires setup. If your only need is code completion in an IDE, a single-provider plugin is simpler. If you want an agent that can operate across your whole system and you value control over convenience, goose is the more flexible path.

Maintenance and upgrade cost, and license implications

goose is licensed under Apache-2.0, which is permissive: you can use, modify, and distribute it, even in commercial products, as long as you retain the license notice. That is a low-friction license for most teams. The maintenance cost is tied to the release cadence. With releases every one to two weeks, you will likely want to track updates for bug fixes and security patches. The README does not mention a long-term support branch or an upgrade guide. The diagnostics and reporting page suggests there is a telemetry or logging mechanism, which you should review to understand what data is sent and how to disable it. The project is part of the Linux Foundation's AAIF, which implies a governance model with multiple stakeholders, but the README links to a GOVERNANCE.md file for details. Before adopting, you should read that file and the CUSTOM_DISTROS.md to understand how the project is steered and whether a distro you build will be compatible with future releases.

Who should adopt it, and what to verify first

goose is a good fit for a developer who wants a local, extensible agent and is willing to invest time in configuration. It is also suitable for teams that want to avoid vendor lock-in, since it supports many providers and uses open standards like MCP. It is a poor fit for a non-technical user who expects a zero-configuration tool, or for a team that needs a stable API for production automation, given the rapid release cycle. Before adopting, verify that your preferred LLM provider works with goose, either via API key or ACP. Check the known issues page for your operating system, because the README does not list any platform-specific caveats. Test the CLI installer in a disposable environment first, because the curl pipe to bash method offers no checksum verification. If you plan to build a custom distribution, read CUSTOM_DISTROS.md to see what is involved and whether it is a supported path or a side project. The project is active, the license is permissive, and the architecture is sound, but the agent's ability to execute commands means you should test it in a sandbox before letting it touch your real files.

Editorial conclusion

Adopt goose if you want a local, extensible AI agent that works across many LLM providers and MCP extensions, and you are comfortable with Rust-based tooling and the Linux Foundation's governance. Do not adopt it if you need a minimal, single-provider tool with a tiny footprint, or if you require a stable API that is not tied to a fast-moving release cycle. Before committing, verify that your preferred LLM provider is supported through the documented ACP flow, check the known issues page for your OS, and test the CLI installation on a staging machine, since the curl pipe to bash method gives you no checksum verification.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes