Skip to main content
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. 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:

​
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.

​
Create a checkpoint repository

Create a separate, empty repository for checkpoint data, then run this from your project: 
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: 
{
  "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: 
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: 
{
  "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 for details.