A new model name is easy to mistake for a new capability. On July 27, Goose added Claude Opus 5 to its provider map, including provider-specific entries, a model-resolution test, and a test for the model family’s adaptive-thinking request format. That is a concrete compatibility change, not a vague “supports more models” claim. It is also a useful moment to notice where an open agent runtime’s real authority lives.
Goose presents itself as a desktop app, CLI, and API that runs on a person’s machine and connects models to extensions. Its fresh code makes the portability layer visible: a canonical model table maps a provider-and-model identity to capabilities, while the Anthropic formatter adapts the request shape for this model family. The portability is deliberate engineering. But mapping a new provider says nothing by itself about which local actions the resulting agent may take.
The port is not the policy
That distinction matters because the next layer is not abstract. Goose’s extension guide says extensions connect applications and tools through MCP; it also warns that autonomous operation, combined with the default Developer extension, can execute commands and modify files without approval. The runtime’s breadth—more model routes, more extensions, more local workflows—therefore expands the place where an operator has to decide what is acceptable.
The project has a named control surface for that decision. Its permission documentation describes Autonomous, Manual Approval, Smart Approval, and Chat Only modes, and identifies Autonomous as the default. In the public source, the permission inspector separately handles explicit user rules, read-only annotations in Smart Approval, extension management, and unknown tools. This is not proof that every classification is right. It is evidence that “which model?” and “what may it do here?” are separate questions in the product’s own design.
One runtime, several kinds of trust
Goose is not only moving models through its compatibility layer. A July 26 documentation-root change lets its built-in documentation skill use a local or HTTP(S) documentation root, with a documented air-gapped option. That is a small but revealing boundary: a runtime can keep its instructions near the environment in which it works instead of assuming the public web is always reachable. The same pattern appears in permission modes. Portability is most useful when the operator can say which sources, tools, and approvals travel with it.
For a team considering a new Goose model route, the practical first test is not a benchmark. In a non-sensitive workspace, select the intended permission mode, add only a known extension, and record what the agent asks, what it is allowed to do, and what happens when it reaches an unfamiliar tool. Then compare that trace after changing the model. The test will not prove safety, but it can expose whether the authority boundary stayed understandable while the compatibility layer changed.
The cited commits prove source changes and targeted tests; they do not establish release inclusion, a working provider account, extension behavior in every build, or production reliability. The next signal worth watching is a public end-to-end receipt that exercises a newly mapped provider alongside a local extension under each permission mode. Until then, the honest claim is narrower: Goose can make a new model legible to its runtime, but it leaves the keyholder’s decision where it belongs—with the person running it.