# Goose

Block's Goose CLI.

- **Source:** `src/providers/goose.ts`
- **Loading:** lazy (`src/providers/index.ts:29-42`)
- **Test:** none. Adding a fixture-based test is a known good first issue.

## Where it reads from

A SQLite database. Path resolution honors `XDG_DATA_HOME` and a `GOOSE_PATH_ROOT` override:

| Platform | Default path |
|---|---|
| macOS / Linux | `~/.local/share/goose/sessions/sessions.db` |
| Windows | `%APPDATA%/Block/goose/sessions/sessions.db` |

See `goose.ts:52-62`.

## Storage format

SQLite.

## Caching

None.

## Deduplication

Per `sessionId` (`goose.ts:174`).

## Quirks

- Source paths are encoded as `<dbPath>:<sessionId>` so a single db can yield many session sources. The discovery code splits on the last colon (`goose.ts:148-150`).
- Tool inventory comes from the `messages` table queried with `LIKE '%toolRequest%'` (`goose.ts:90`). This will miss tools whose payloads are encoded differently in a future Goose version.
- Tokens are read directly from `accumulated_input_tokens` and `accumulated_output_tokens`. No estimation.

## When fixing a bug here

1. Add a fixture-based test before changing logic. `tests/providers/goose.test.ts` does not exist yet; create it and use a small SQLite file under `tests/fixtures/goose/`.
2. If the bug is "no sessions", check `XDG_DATA_HOME` and `GOOSE_PATH_ROOT` first; users on non-default Linux setups will not match the default path.
3. The `LIKE '%toolRequest%'` query is fragile. If Goose changes the message envelope, this is where it will break.