goose

Not restorable in one action: the local files are complete and immediately available, but there is no whole-agent export or import, so config.yaml, memory files and keyring secrets must be copied or re-entered by hand (sessions export and import only one at a time).

• goose docs: session management
• goose docs: configuration files

Everything that defines the agent sits in documented local files (config.yaml, permission.yaml, prompts/, memory/, recipes and sessions.db), so a copy of those locations is complete and nothing is held by the project. Secrets default to the OS keyring and must be moved separately.

• goose docs: configuration files
• goose docs: logging system

goose is Apache-2.0 software that runs entirely on the owner's machine with no required foundation server, and its built-in local inference or Ollama allows fully offline operation.

• aaif-goose/goose
• goose blog: built-in local inference

goose has no agent identity that others could check after a migration; sessions and installations carry only local identifiers.

• goose docs: configuration files

There is no license check, account requirement or remote feature flag. Governance and the trademark sit with the Linux Foundation's AAIF, and the desktop app's update check can be controlled by the owner.

• goose moves to AAIF
• goose docs: updating goose

Tools come from MCP extensions and built-ins executed by the goose runtime, so they stay available with any supported provider, including local models. Models without native tool calling can use an experimental tool shim.

• goose docs: providers
• goose docs: Ollama tool shim

Config is YAML, sessions are in a documented SQLite database that can be queried with sqlite3, memories are text files, and logs are JSON/JSONL.

• goose docs: configuration files
• goose docs: session management

Default prompt templates are published in the open-source repo, and nine of them (including system.md) can be overridden. Recent LLM requests, including the full input payload, are also logged locally as JSONL.

• goose docs: prompt templates
• goose docs: logging system

goose has no hosted backend holding user data, and the docs say its log files stay local. Opt-in usage data excludes conversations and code, although opted-in events carry a stable installation identifier. Model providers apply their own policies.

• goose docs: anonymous usage data
• GitHub issue #12303

Every session's messages, including tool requests and responses, are stored in the local sessions.db and can be exported per session as JSON. CLI logs also capture tool calls but are deleted after two weeks.

• goose docs: logging system
• goose docs: session management

Recipes are YAML files, hints and prompt templates are Markdown, and the runtime is open-source Rust and TypeScript. MCP extensions are separate programs whose readability depends on the extension.

• aaif-goose/goose
• goose docs: prompt templates

No advertising or sponsored-content channel was found. Third-party content reaches the context only through extensions the owner enables, and the owner can view and disable them.

• goose docs: tool permissions

Tool requests and results are stored durably in sessions.db, but only after the tools have run, so an action still takes place if its record cannot be written.

• goose source: agent.rs
• goose docs: logging system

Session rows and log files can be edited or deleted without any trace. Logs also rotate: CLI and server logs after two weeks, and LLM request logs after the last 10 requests.

• goose docs: logging system

The Developer extension's shell and file tools run as the user without a sandbox, so the agent can modify sessions.db and its logs. Permissions only allow, ask for or block whole tools, and the default autonomous mode asks for nothing.

• goose docs: Developer extension
• goose docs: permission modes

Session records (SQLite), CLI logs (JSON) and LLM request logs (JSONL) can be read with general-purpose tools.

• goose docs: logging system

Orchestrator subagent sessions are stored in sessions.db with their parent session ID, and the parent's tool calls name the subagent session they address, so both sides log a shared identifier. goose has no channel to independent agents beyond this.

• goose source: orchestrator.rs
• goose docs: subagents

The runtime is open source under Apache-2.0, an OSI-approved license. No reproducible-build process or verification was found in the public documentation.

• aaif-goose/goose
• goose releases

Behavior comes from config.yaml, permission.yaml, prompt overrides and documented GOOSE_* environment variables, all of which the owner can inspect. Cached smart-approval decisions are also written to permission.yaml.

• goose docs: configuration files
• DeepWiki: permission modes

Recipients have no way to verify that a message came from a particular goose agent: outbound content carries no signature or other attribution the agent controls.

• aaif-goose/goose

The session store and logs carry no integrity data, so no tool can check whether the record is intact.

• goose docs: logging system

All state is in local YAML, text and SQLite files, so the owner can copy it at two points in time and compare the copies with open tools such as diff and sqldiff.

• goose docs: configuration files
• goose docs: logging system

The system prompt and eight other templates can be overridden in ~/.config/goose/prompts, and .goosehints and recipes add owner instructions. Templates that cannot be overridden remain editable in the Apache-2.0 source.

• goose docs: prompt templates

Memory extension entries are categorized text files in ~/.config/goose/memory that can be viewed, edited or deleted directly, and sessions can be removed.

• goose docs: Memory extension
• goose docs: session management

Owners can write recipes and custom MCP extensions and modify the open-source runtime.

• aaif-goose/goose

Any MCP server can be added as an extension, and each tool can be set to always allow, ask before or never allow.

• goose docs: tool permissions

goose supports 15+ providers plus built-in local GGUF inference and Ollama, and its tools belong to the runtime. Tool-use quality varies by model, and non-tool-calling models rely on the experimental shim.

• goose blog: built-in local inference
• goose docs: providers

goose has no paid tier, license check or approval requirement for modifications.

• aaif-goose/goose
• AAIF: goose

goose contacts external parties only through extensions the owner enables, and each tool can be set to always allow, ask before or never allow. The owner cannot limit which recipients, hosts or domains a permitted tool reaches, so an allowed shell tool can contact any host.

• goose docs: tool permissions
• goose docs: Developer extension

Manual Approval mode and per-tool Ask Before or Never Allow settings are enforced by the runtime before a tool runs. Smart Approval, where an LLM judge decides, is optional.

• goose docs: tool permissions
• DeepWiki: permission modes

goose runs as a local process: Ctrl+C in the CLI or the stop control in the desktop app interrupts it, and the owner can kill the process at any time.

• goose docs: session management

Usage data is opt-in (GOOSE_TELEMETRY_ENABLED defaults to false), excludes content, and model traffic goes only to the provider the owner chooses. The desktop app checks for updates by default, and a past bug caused updates to download even when automatic downloads were disabled.

• goose docs: anonymous usage data
• goose docs: configuration files
• GitHub issue #10300

Secrets stay under the owner's control in the OS keyring or a local secrets.yaml, with nothing held by the project. Keyring-stored secrets do not travel with a file copy and must be migrated by hand.

• goose docs: configuration files

All state sits in local directories and the keyring, which the owner can delete completely, and the foundation holds nothing to retain. Data already sent to model providers follows their policies.

• goose docs: logging system
• goose docs: configuration files