# Kilo Code

> Import Kilo Code CLI, IDE, legacy task, and cloud histories with tools, usage, and memory files.

Kilo Code's current CLI, VS Code extension, and JetBrains plugin share a local
SQLite store. Earlier extensions and CLI releases used JSON task directories.
Hansard reads both generations and supports explicit cloud imports.

## Source IDs

| Source             | Use it for                                                  |
| ------------------ | ----------------------------------------------------------- |
| `kilo-code`        | Current CLI and IDE SQLite sessions.                        |
| `kilo-code-legacy` | Earlier IDE and CLI JSON tasks.                             |
| `kilo-code-cloud`  | Synchronized cloud exports or targeted Cloud Agent results. |

## How the import works

The current store is `~/.local/share/kilo/kilo.db`, including on macOS.
`XDG_DATA_HOME` changes its parent directory. `HANSARD_KILO_CODE_DATA_ROOTS`
accepts a path-separated list of Kilo data directories. The originating CLI or
IDE interface is not reliably recorded, so these clients share one source.

Legacy tasks live under the editor's `User/globalStorage/kilocode.kilo-code/tasks`
or `~/.kilocode/cli/global/tasks`. Standard VS Code-family and remote-server
homes are checked; `HANSARD_KILO_CODE_TASK_ROOTS` accepts alternate storage
homes. Per-task history files take precedence over shared indexes or mementos.
Migrated tasks use Kilo's deterministic migration identity. A corresponding
current SQLite session takes precedence over the old task copy.

SQLite reads use a coherent snapshot that includes committed WAL records.
The preserved history snapshot excludes credential, account, and session-share
tables and clears share URLs. Conversation tables, pending inputs, todos, and
collaboration-board history remain preserved. Provider stores remain unchanged.

Cloud imports use `KILO_API_KEY` and read-only requests to Kilo's session listing
and export services. Earlier cloud tasks use the legacy session-detail endpoint
and signed transcript blobs; signed URLs and bearer credentials are not archived.
A synchronized export with an exact local identity does not replace local history.
For the separate Cloud Agent result API, both the `agent_...` session ID and
`msg_...` message ID are required. That API returns status and final text only.

## Import and keep current

**Import now**

```sh
hansard import --sources kilo-code,kilo-code-legacy --since all
hansard index rebuild
```

With `KILO_API_KEY` available:

```sh
hansard import kilo-code-cloud --since all
```

**Keep current**

**Automatic** source selection includes both local stores. For a **Custom** list:

```sh
hansard config sources enable kilo-code,kilo-code-legacy
hansard watcher restart
```

The watcher refreshes `kilo-code-cloud` every six hours only after you turn on
**Kilo Code Cloud** in **Settings → Imports → Cloud agents**.

## Review the import in the app

1. When the import finishes, open **Conversations** and select **Filter & sort**.
2. Set **Source** to **Kilo Code** and set **Time** to the window you imported. Use **Folder** to narrow the list when you use this harness in several projects.
3. Select a conversation to check its messages, tool calls, files, commits, model, and token usage.

To keep archiving new sessions from a local harness, open **Settings → Imports**. **Automatic** follows every supported harness installed on this computer. **Custom** lets you turn individual harnesses on or off. Cloud sources and account exports never run from here; each needs its own import command. If a conversation you expect is missing after you reset the filters, run the import command on this page again with `--explain-skips` where the source supports it.

## What Hansard preserves

- Human messages, assistant replies, recorded reasoning, compaction context,
  tool arguments and results, errors, attachments, and numbered edit diffs.
- Recorded model IDs, directional tokens, cache reads and writes, reasoning
  tokens, and cost. Step accounting is counted once; reasoning output remains
  separate from visible output. Ambiguous recorded cost remains estimated.
- Titles, folders, timestamps, recorded agent settings, parent/child lineage,
  todos, pending inputs, and collaboration-board records.
- Global and project `.kilo` and `.kilocode` rules, agents, commands, workflows,
  custom modes, and project memory files through `hansard memory backup`.
  Credential configuration, compiled memory indexes, checkpoints, and caches
  are excluded from the memory archive.
- Native resume commands for current `kilo.db` stores. Resumed conversations
  update their existing archive identity.

## Known limitations

- Legacy task histories often omit model IDs and individual API message clocks.
  Current configuration is never used to invent historical values.
- Current IDE formats and child sessions are fixture-tested; the released CLI
  was exercised with a local model endpoint through read, edit, and resume.
  Authenticated cloud acquisition is covered by simulated API responses, without
  a live account trial.
- Cloud Agent result lookups cannot supply the original prompt, tool history,
  model, or token usage. Synchronized exports provide the fuller history when
  available. No history is recoverable after provider deletion unless it was
  already archived.
- Unsupported schemas or malformed records produce import errors. Unrecognized
  part kinds are counted in session metadata and retained in raw history.

## Refresh an existing archive

```sh
hansard import --sources kilo-code,kilo-code-legacy --since all
hansard index rebuild
```

Rerun the explicit cloud import to refresh cloud history. No archive migration
is required to enable these sources.