# Inside goose: the moving stable tag, the exact ACP pin, and a CLI-only container

> goose is a Rust AI agent from the Agentic AI Foundation that ships as a desktop app, a CLI, and an API. Its own repo files show the real constraints: an installer piped from a moving channel, an ACP schema crate frozen at one exact version, and a Docker image that carries the CLI alone.

**aaif-goose/goose** — an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM.

- Repository: https://github.com/aaif-goose/goose
- Website: https://goose-docs.ai/
- Stars: 54,775 · Forks: 6,341
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/aaif-goose-goose

## The install command pipes a script from a moving tag

The only install command here is a pipe to bash pointed at a channel rather than a version, because the URL path ends in releases/download/stable/download_cli.sh. Whatever that resolves to at the moment you run it is the script you execute. Nothing in the line checks a checksum or a signature, and there is no version argument to freeze the install. Two consequences follow. A machine provisioned twice on different days can end up with different goose binaries under an identical command, so provider defaults, extension compatibility, and agent behavior can shift without any change on your side. And the script runs with the full privileges of the invoking shell, before you have read what it does. Alternatives do exist: a Repology badge points at a page listing goose-cli versions per distribution, and download_cli.ps1 sits in the repository root for PowerShell, though neither is shown as a command here.

## The ACP schema crate is held at one exact version

Three agent-client-protocol crates appear in the workspace dependencies. Two move on a caret range, agent-client-protocol at 2.2.0 and agent-client-protocol-http at 2.2.0. The third, agent-client-protocol-schema, is declared as =1.9.1 with the equals sign inside the version string, which tells cargo to refuse any other version. That schema is therefore the one part of the ACP stack that cannot drift during a routine update, and it sits a full major series below the protocol crates that consume it. If a later 2.x release of the protocol crate expects a newer schema, resolution fails outright and the repair is a hand edit in Cargo.toml plus a retest of the integration. The README also routes readers to a guide at goose-docs.ai/docs/guides/acp-providers for using existing Claude, ChatGPT, or Gemini subscriptions in place of API keys, so anyone building an editor against goose should check that guide against the pinned schema.

## Default features are off, so the feature list is the real spec

Nearly every entry in the workspace dependencies block sets default-features = false and then names features by hand. rmcp, the MCP client, is enabled only with schemars. axum carries http1, http2, json, tokio, and query. clap lists derive, std, help, suggestions, usage, color, and error-context. anyhow gets std. The effect is that goose's compiled surface is written out in one file instead of inherited from upstream defaults. For a user this has one sharp edge: an extension that needs a transport or capability missing from that list is not something you switch on at runtime. It becomes a source change, a rebuild, and a release, or a request to the maintainers. The clippy table is written the same explicit way, with uninlined_format_args set to allow and string_slice to warn. A binary built from this manifest and one from a distribution package are not guaranteed to expose the same set, so compare the two before debugging an extension that refuses to connect.

## The container is CLI only, and its builder predates the toolchain the manifest requires

The Dockerfile is a two stage build. The builder is rust:1.82-bookworm, installs cmake, protobuf-compiler, libclang-dev, and libssl-dev among other packages, sets the release profile, and runs a single cargo build of the goose-cli package. The runtime stage is debian:bookworm-slim pinned by digest, and it copies exactly one artifact, /build/target/release/goose, into /usr/local/bin. The file's own comment calls the image the goose CLI and Server Docker Image, yet the entrypoint is the goose binary and the default command is --help, so nothing in the image starts a server and nothing draws the desktop app for macOS, Linux, and Windows. The container covers the terminal surface only. There is a version conflict to reconcile as well, since rust-version in Cargo.toml is 1.94.1 while the builder tag is 1.82. Both files are in the repository, and until they agree, a failed image build is how you find out which one is stale.

## Stripped symbols and a runtime with no compiler

The builder sets four cargo environment variables before compiling, and they govern what you can do after a failure:

```
ENV CARGO_PROFILE_RELEASE_LTO=true
ENV CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
ENV CARGO_PROFILE_RELEASE_OPT_LEVEL=z
ENV CARGO_PROFILE_RELEASE_STRIP=true
RUN cargo build --release --package goose-cli
```

The first three trade build time for a smaller binary and the last removes symbols from it, which is a sensible container default. A panic from that image then gives you an address and no function name, and the runtime stage carries no rustc, no cargo, and no compiler, so you cannot rebuild the same package with debug info inside the container to recover them. The runtime package list is short on purpose, ca-certificates, libssl3, libdbus-1-3, libgomp1, libxcb1, curl, and git, which makes a missing shared library an image change rather than something you can patch. libgomp1 and libxcb1 are native library packages that the README never mentions, so the reason the binary needs them is visible only in the Dockerfile.

## State lives under /home/goose/.config/goose, owned by uid 1000

The image creates a non-root account with useradd -m -u 1000 -s /bin/bash goose, makes /home/goose/.config/goose, chowns the tree, sets HOME to /home/goose, and only then drops privileges with USER goose. The agent's working state and any provider credentials entered into it are therefore expected to live under a home directory that already exists in the image with a fixed numeric owner. Two operational consequences follow. If you bind mount a volume over that path, the ownership baked into the image is hidden, and a volume created as root will not be writable by uid 1000; the fix is a chown on the host side, and the symptom if you skip it is a permission error rather than an obvious configuration mistake. And without a volume, anything goose stores there, API keys included, stays in the container layer and disappears when the container is replaced. The runtime image ships curl and git, so that container can fetch code and reach the network, which is worth weighing before mounting a credential directory into it.

## 70+ extensions and 15+ providers, with no permission model named anywhere

The README claims work with 15+ providers, naming Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, and Bedrock, plus connections to 70+ extensions through the Model Context Protocol open standard. Both numbers describe a catalog rather than a guarantee. Every extension is third-party code the agent connects to over that protocol, running with whatever access the agent itself has, and the README names no permission prompt, allowlist, or sandbox, pointing instead to the documentation site and a known issues page. That silence matters for anyone planning to use goose for what its own description leads with, which is installing, executing, editing, and testing. The two provider paths also ask different things of you. API keys are explicit, while the ACP route reuses an existing Claude, ChatGPT, or Gemini subscription behind a guide held in separate documentation, so read it before assuming an entitlement carries over.

## main is already at 1.53.0, and three point releases landed in ten days

The workspace version in Cargo.toml is 1.53.0, ahead of the newest tag, v1.52.0 dated 2026-09-23. Below that sit v1.51.0 on 2026-09-17 and v1.50.1 on 2026-09-14, and the last push to main is 2026-09-29. That is a brisk cadence for a tool that can run code, and it cuts both ways for an adopter. Because the installer follows the stable channel rather than a version, new builds reach a machine without a deliberate upgrade, so a behavior change can land between two runs of the same task. On governance, the project sits in the Agentic AI Foundation at the Linux Foundation and ships GOVERNANCE.md, MAINTAINERS.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, and SECURITY.md, alongside a Justfile, deny.toml for dependency review, and release-plz.toml. Note that the author field in Cargo.toml reads AAIF with a block.xyz contact address, so foundation membership and corporate contact are two separate facts, and MAINTAINERS.md is where you find who lands commits.

## Conclusion

Choose goose if you want an agent that runs on your own machine across a desktop app, a CLI, and an API, and if you can live with a release cadence this fast. Before you depend on it, pin a version instead of taking whatever the stable channel serves, confirm the pinned ACP schema still covers the editor you integrate with, and read the permission model in the goose documentation before letting it load MCP extensions.

## FAQ

### what is goose ai

goose is an Apache-2.0 AI agent written in Rust that runs on your machine as a desktop app for macOS, Linux, and Windows, a CLI for terminal work, and an API to embed elsewhere. It is part of the Agentic AI Foundation at the Linux Foundation and connects to 70+ extensions over the Model Context Protocol.

### how to install goose ai

The desktop app comes from the installation page linked for macOS, Linux, and Windows, while the CLI has its own installer command. A Custom Distributions guide also exists for building a goose distro with preconfigured providers, extensions, and branding.

### how to install goose cli

The single command given is a curl pipe to bash against the download_cli.sh script under the stable release channel, so it installs whatever that channel points to at the time. A PowerShell counterpart, download_cli.ps1, is committed in the repository root.

### how to install goose

Distro packages are one route, since a Repology badge tracks goose-cli versions per distribution. Another is building from source: the repository ships BUILDING_LINUX.md, a Justfile, and a Dockerfile that compiles the goose-cli package into a Debian runtime image with the goose binary as its entrypoint.

## Sources

- [Official documentation](https://goose-docs.ai/)
- [Official README](https://github.com/aaif-goose/goose#readme)
- [Project repository](https://github.com/aaif-goose/goose)
- [Release notes](https://github.com/aaif-goose/goose/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aaif-goose-goose