> ## Documentation Index
> Fetch the complete documentation index at: https://docs.entire.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Store Checkpoint Data

> Choose where Entire stores checkpoint history for a repository.

Entire stores checkpoint data separately from your normal source branches. By default, that data is written to a dedicated Git branch in your code repository named [`entire/checkpoints/v1`](/glossary#checkpoints-branch).

Your code stays on your regular branches, while prompts, transcripts, session context, and checkpoint metadata live in checkpoint storage.

## Choose where checkpoints go

By default, checkpoints stay with the repository they describe. This keeps the code and the context behind the code together.

You can change that default when checkpoint history should follow a different storage or access boundary:

* [keep checkpoints with the code repository](#store-checkpoints-with-your-code)
* [push checkpoints to a separate repository](#store-checkpoints-in-another-repo)
* [keep checkpoints local on your machine](#keep-checkpoints-local)

## Store checkpoints with your code

By default, Entire stores checkpoint data in the same Git repository as your code on the `entire/checkpoints/v1` branch.

This is the recommended setup for most repositories. It keeps the development record together: the commit, the checkpoint, and the agent context that produced the change.

Your normal Git history stays clean. Entire does not add checkpoint data to your working branch.

## Store checkpoints in another repo

If checkpoint history should live somewhere other than the source repository, configure a [checkpoint remote](/glossary#checkpoint-remote).

### Create a checkpoint repository

Create a separate, empty repository for checkpoint data, then run this from your project:

```bash theme={null}
entire configure --checkpoint-remote github:owner/repo
```

Replace `owner/repo` with the repository you created for checkpoint data.

The value uses the format `provider:owner/repo`. Currently, `github` is the supported provider.

### Settings

This writes the checkpoint remote to `.entire/settings.json`:

```json theme={null}
{
  "strategy_options": {
    "checkpoint_remote": {
      "provider": "github",
      "repo": "owner/repo"
    }
  }
}
```

After this is configured, your code continues to live in the main repository, while checkpoint data is pushed to the separate repository.

Commit and push `.entire/settings.json` when the checkpoint remote should apply to the whole project. Entire.io uses that setting to locate checkpoint data.

### When to use another repo

This is useful when:

* checkpoint data should follow a different sharing boundary than source code
* your team keeps development metadata outside the source repository
* you want to keep the source repository focused on source code

### Push behavior

When you push code, Entire pushes `entire/checkpoints/v1` to the checkpoint repository separately. It uses the same protocol as your Git remote, such as SSH or HTTPS.

If the checkpoint repository cannot be reached, your main Git push still succeeds. Entire keeps the checkpoint data locally and warns that it could not sync.

### Keep checkpoints under the same owner

Use a checkpoint repository with the same owner or organization as your code repository:

* **Same owner** — checkpoints push normally. If your code is at `github.com/acme/app`, a checkpoint repo like `github:acme/app-checkpoints` works because both are owned by `acme`.
* **Different owner** — Entire won't push checkpoint data to that repository.

The different-owner case is an intentional design to protect forks, keeping fork contributors from needing write access to the upstream project's checkpoint repository.

## Keep checkpoints local

When checkpoint history should stay on your current machine, keep it local:

```bash theme={null}
entire configure --skip-push-sessions
```

Entire will still capture checkpoint data on your machine, but it will not push that data to GitHub or another remote.

This is useful for local experiments or repositories where you do not need checkpoint history available from another device. The tradeoff is that teammates cannot review local-only checkpoints unless you share them another way.

This writes `push_sessions: false` to `.entire/settings.json`:

```json theme={null}
{
  "strategy_options": {
    "push_sessions": false
  }
}
```

## Settings files

Storage settings are written to `.entire/settings.json` by default, so they can be shared with the repository.

For personal preferences that should not affect the rest of the team, use the `--local` flag to write to `.entire/settings.local.json` instead.

Local settings apply only to your clone and take precedence over project settings. See [Local, Project, and Global Settings](/guides/configuration/settings-layers) for details.