Goose2 distro bundles
A Goose2 distro bundle is an optional app-specific package of configuration and policy that the Tauri shell loads at startup.
What a distro bundle is
A distro bundle lives under ui/goose2/distro/ in development, and is bundled into the packaged app as a Tauri resource in production.
Current supported files:
distro.json— distro manifestconfig.yaml— optional Goose config passed togoose servebin/— optional executables or helper scripts prepended toPATHforgoose serve
How it is discovered
The Tauri app resolves the distro bundle in this order:
GOOSE_DISTRO_DIR, if set- bundled Tauri resource dir at
resource_dir()/distro
In development, just dev and just dev-debug automatically export GOOSE_DISTRO_DIR to ui/goose2/distro when that directory exists.
Manifest shape
Example:
{
"appVersion": "development",
"featureToggles": {
"costTracking": false
},
"providerAllowlist": "databricks"
}
Fields
-
appVersion?: string- optional app version tag supplied by the distro
-
featureToggles?: Record<string, boolean>- optional UI/product flags controlled by the distro
- currently supported:
costTrackingfalsehides cost UI in the token/context usage surfaces- omitted behaves as enabled
-
providerAllowlist?: string- comma-separated provider ids
- suggests which model providers to show in Settings
- suggests which Goose model options to show in the chat model picker
-
extensionAllowlist?: string- comma-separated extension ids
- reserved for future UI suggestions
Runtime effects
When a distro bundle is present, Goose2 does two kinds of things with it.
Frontend behavior
The frontend loads get_distro_bundle during app startup and stores the manifest in Zustand.
Today it uses that manifest to:
- filter model providers shown in provider settings via
providerAllowlist - filter Goose model options shown in the chat input model picker via
providerAllowlist - hide cost UI when
featureToggles.costTracking === false
These allowlists are UI suggestions only. They do not enforce backend access control and do not invalidate existing sessions or saved model choices.
Backend / shell behavior
When the Tauri shell launches the long-lived goose serve process, it applies the distro bundle like this:
- prepends
distro/bintoPATHwhen present - adds
distro/config.yamltoGOOSE_ADDITIONAL_CONFIG_FILESwhen present - sets
GOOSE_DISTRO_DIRto the resolved distro root
This is shell-level behavior, so it is implemented as Tauri-side setup rather than an ACP method.
Development notes
- packaged apps discover distro content from bundled Tauri resources
- local development uses
GOOSE_DISTRO_DIR - after changing
distro.json, restartjust devso startup reloads the manifest
Scope guidance
Use distro bundles for packaged-app policy and shell-level defaults.
Good fits:
- feature flags for Goose2 UI behavior
- allowlists that suggest visible product choices
- config or helper binaries that should be present when
goose servestarts
Avoid using distro bundles as a replacement for normal app state, user settings, or ACP-backed domain data.