# goose connects to a model but a local extension is unavailable

Diagnose unavailable Goose extensions through activation, process startup, command availability, tool permissions, and local model tool support.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/goose-local-extension-not-found/
Language: en

If Goose reaches the local model but cannot use an extension, diagnose the extension independently. Provider connectivity proves generation, while an extension still needs activation, a working process or service, and a model able to invoke its tools.

## The concrete application boundary

Goose extensions are based on MCP. Built-in extensions and externally configured servers have different startup dependencies. The Developer extension is documented as enabled by default and can execute commands or modify files under the application’s permission behavior. External command-line extensions instead depend on their configured executable, arguments, environment, and working scope. An entry in the extension list does not prove successful startup. The provider guide also warns that models without tool calling are limited to chat and require extensions disabled. Therefore a fluent response is weak evidence about an unavailable file tool. Check the actual capability and its observed result rather than the assistant’s claim that it inspected something ([Goose official repository](https://github.com/aaif-goose/goose)).

## A practical route

Open the Desktop sidebar and Extensions. Inspect whether the relevant extension is enabled; for a custom entry, review its configured type and command details. The CLI route uses goose configure, then Add Extension or the relevant toggle workflow. For an existing command-line extension, confirm the executable exists on the local host and that the application process receives the required environment. Keep credentials out of shared diagnostic notes. Start a fresh bounded task and ask for one read-only observation that the tool can actually provide ([Goose extension guide](https://goose-docs.ai/docs/getting-started/using-extensions/)).

## A worked example

A local note extension is listed but its launcher cannot start in the application environment. Goose still answers general questions from the model, so the user assumes the extension must work. Correct the command availability and recheck activation. Ask for a distinctive fictional line in a disposable note, then inspect the actual tool return. The line should not be supplied in the question, which would let a model answer without reading.

| Check | Record |
| --- | --- |
| Activation | The intended extension is enabled in the current application configuration. |
| Startup | Its configured local command or service actually becomes available. |
| Tool result | The distinctive note line appears in an observed tool return. |

## Reading the failure correctly

A permission decision can block an otherwise available tool, while an unsupported model can fail to invoke it. These differ from a process that never started. Do not solve every case by enabling unrelated extensions or setting broad automatic approval. Evaluate the specific requested action and the current local-model capability ([Goose provider configuration](https://goose-docs.ai/docs/getting-started/providers/)).

## What completes the check

A repaired extension produces an inspectable tool result under the intended scope. The local model connection remains a separate baseline, making later startup or permission failures easier to distinguish without replacing the generator.

Related background: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/), [Coding LLMs on 12GB VRAM: Budget Context and Headroom](/journal/coding-llm-12gb-vram/).