goose

Desktop has an in-app Export and Import pair for sessions (JSON), and the CLI has `goose session export`; both work at once on the owner's machine. Restoring the rest of the agent (config.yaml, permission.yaml, memory files, prompt overrides, skills, schedules, keyring secrets) means copying files and re-entering keys by hand, and there is no documented procedure for it. That is one shortfall.

• Session Management (import/export)
• Configuration Files

The only export is the session file (conversation, tool calls with arguments, metadata). Config, memory, prompt overrides, skills/recipes, schedules and credentials are not in it. All of these stay on the owner's disk at documented paths, the provider holds none of them, and integrations re-link with the owner's own keys. So neither fail condition is literally met, but more than one class is missing from the export, so this does not reach pass.

• goose Logging System (storage locations)
• Session Management
• Memory extension

The runtime is Apache-2.0 and has no licence check, account or provider service in the core. Local inference is a default build feature, and the docs root and other endpoints are configurable. Settled only hands-on; credited here from source.

• LICENSE (Apache-2.0)
• goose-cli Cargo.toml default features (local-inference)

Any provider can be chosen, including built-in local inference and Ollama. A tool shim and a tiny-model prompt cover models without native tool calling, and dictation has a local Whisper option. But Desktop's Live Voice feature has only an OpenAI realtime implementation, so it is lost on other models.

• openai_live_voice_provider.rs
• LLM Providers
• Onboarding ProviderSelector.tsx

All agent state is local-first on the owner's device, and there is no account whose termination could cut off access.

• goose Logging System

Sessions are in a documented SQLite database whose schema is in the open source. Config is YAML, memory and prompts are text/Markdown, LLM request logs are JSONL, and secrets sit in the OS keyring or secrets.yaml under the owner's control.

• goose Logging System
• Configuration Files

Each LLM request's full payload is written locally to llm_request.*.jsonl, including the system prompt, turn-context blocks and compaction output. Only the 10 most recent are kept, which is an edge-path gap and is not counted. Model, mode, extensions and tool permissions are all visible in config and settings.

• goose Logging System (LLM Request Logs)
• providers/utils.rs request logger

Operation is local. Telemetry is opt-in and anonymous, and the provider holds no content or profile. Model-provider data handling is the owner's chosen destination.

• Anonymous Usage Data
• posthog.rs

Nothing in the source shows paid placement, and no provider or model is preselected. However, onboarding sorts a hard-coded 'Preferred' set of providers first, the criteria for that set are not disclosed, and it cannot be switched off. There is no binding no-steering commitment.

• ProviderSelector.tsx (Preferred sort)
• providers/init.rs (preferred registrations)

Tool calls with arguments from user, subagent and scheduled sessions are stored durably in sessions.db. But hook executions (Open Plugins hooks, which also auto-load from project directories) appear only in logs that are deleted after two weeks. No public evidence says the owner is alerted when a record write fails, so under G12 that shortfall counts as present. Two shortfalls.

• Hooks
• goose Logging System (two-week log cleanup)

The session database and logs carry no hashes, signatures or checkpoints, so any edit leaves no trace.

• goose Logging System

In the default Autonomous mode, with no sandbox, the Developer extension's shell can write to ~/.local/share/goose/sessions/sessions.db and the log directories. Nothing stops the agent from changing its own record.

• goose Permission Modes (Autonomous is default)
• goose Logging System

All components, including the Electron Desktop app and goosed, are Apache-2.0 source. The release workflow attests build provenance for release artifacts (Linux/macOS/Windows bundles, deb/rpm/flatpak, download_cli.sh) using actions/attest-build-provenance (Sigstore/SLSA), which can be checked with `gh attestation verify`. Not verified hands-on.

• release.yml (attest build provenance)
• LICENSE

The default offering gives the agent no identity of its own; it acts only through the owner's credentials for each integration.

• Configuration Files

Changes to settings, permissions, memory files, prompts or extensions are not versioned or attributed, and the product cannot restore them. The only trace is that agent-made memory writes appear as tool calls in the session history. Prompts have 'Reset to Default' only.

• Customizing Prompt Templates
• Configuration Files

system.md, compaction, subagent and other templates can be replaced from the Desktop Prompts tab or ~/.config/goose/prompts, and the overrides persist across updates. Built-in extension instructions, such as developer_instructions(), and the chat-mode injection are hard-coded and can only be changed in source.

• Customizing Prompt Templates
• developer/mod.rs

Persistent memory lives in documented text files: global at ~/.config/goose/memory/ and per-project at .goose/memory/. Hints, AGENTS.md and skills are plain files, and sessions used by Chat Recall can be deleted one by one. All of it can be itemised, edited and deleted.

• Memory extension
• Session Management

Any MCP server (stdio or remote) can be added without review, and every built-in or platform extension can be toggled off. The GOOSE_ALLOWLIST restriction is off by default.

• Using Extensions
• platform_extensions/mod.rs

Most protections are owner settings: permission mode, prompt-injection detection (off by default) and the turn limit. But the OSV malware block on npx/uvx extensions has no documented override. The docs tell the owner to find an alternative or file an issue, and the only way to redirect the check is an undocumented OSV_ENDPOINT environment variable.

• Known Issues: Malicious Package Detected
• extension_malware_check.rs

There are no remote flags, and prompts and the model catalogue are baked into each release. By default Desktop downloads updates automatically and installs them on quit, but the owner can turn this off in Settings > App > Updates ('Disable automatic update downloads') and stay on any version indefinitely. CLI updates are manual. Models are chosen and pinned by the owner.

• autoUpdater.ts
• UpdateSection.tsx
• Updating goose

Limits exist per tool (Always, Ask or Never), but there are no contact or egress limits per recipient or domain. The agent's shell can also edit its own config.yaml and permission.yaml, since nothing sandboxes the config directory. Spend is not applicable (G11): goose has no payment capability. Two shortfalls.

• Managing Tool Permissions
• Configuration Files

The owner can put any tool behind 'Ask Before' in Manual or Smart mode. But scheduled jobs (the Scheduler extension, on by default) always create their agent and session in GooseMode::Auto, which approves every tool, so that path bypasses the gates.

• scheduler.rs (GooseMode::Auto for jobs)
• permission_inspector.rs

The owner can stop the foreground turn. No single documented control also stops scheduled jobs; those must be paused or removed separately. Settled only hands-on.

• scheduler.rs

Telemetry is opt-in and content goes only to the owner-chosen model provider. But Desktop runs an update check against GitHub at every startup, and the owner can turn off only the download, not the check. Adding an npx/uvx extension also sends its package name to the OSV service, with no documented off switch. Both flows run by default and cannot be switched off.

• Anonymous Usage Data
• autoUpdater.ts
• Using Extensions (malware check)

Credentials are held locally in the OS keyring or secrets.yaml, and the provider never holds them. Provider keys can be removed one at a time. However, no documented single view lists every credential and grant, such as extension OAuth tokens, with a revoke control for each.

• Configuration Files (Security Considerations)
• oauth/persist.rs

The provider holds no copies. Full removal is a documented multi-step manual procedure: uninstall, delete the config, share and state directories, and clear keyring entries. There is no confirmation.

• Known Issues: Uninstall goose or Remove Cached Data