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

# Choose Where Checkpoints Are Uploaded

> Control which remote receives checkpoint data when a repository has several.

Entire uploads checkpoints to one place, the checkpoint destination. It is either:

* **One of your existing remotes**, chosen automatically or pinned with `--checkpoint-push-remote <remote-name>`. Checkpoints are uploaded when you run `git push` to that remote.
* **A separate checkpoint repository**, set with `--checkpoint-remote`. See [Store Checkpoints in Another Repository](https://docs.entire.com/guides/checkpoints/store-checkpoints-in-another-repo.md).

The two flags differ by one word but mean different things: `--checkpoint-push-remote` picks which of your remotes receives checkpoints, while `--checkpoint-remote` sends them to a different repository altogether.

`entire status` shows the current destination, where it came from, and how many checkpoints are unpushed. With the default `git-refs` [storage backend](https://docs.entire.com/guides/checkpoints/checkpoint-storage.md), `entire checkpoint list --outgoing` lists them. Every `entire enable` run ends by naming the destination.

## Which Remote Receives Checkpoints

If you push code to several remotes, checkpoints go to exactly one of them. Entire picks it in this order:

1. `strategy_options.checkpoint_push_remote`, if set. If it names a remote that isn't configured, checkpoints don't sync.
2. The remote of your first push whose target matches the branch's configured push destination. Entire announces the choice and keeps it.
3. `origin`
4. The sole remote, if the repository has exactly one
5. The first remote in `.git/config` order

A push to any other remote carries no checkpoint data, unless every push URL of both remotes names the same GitHub repository. For example, `git@github.com:acme/widgets.git` and its Entire mirror `entire://<cluster>/gh/acme/widgets` reach the same repository, so a push to either carries the checkpoints.

## Choose the Remote

When a repository has several remotes that could receive checkpoints, the first interactive `entire enable` asks which one to use, after agent selection and before any hooks or settings are written. Running `entire enable` again in an enabled repository does not ask again.

Choosing a remote saves `strategy_options.checkpoint_push_remote` in `.entire/settings.local.json`, so teammates do not inherit a remote name specific to your clone. Keeping the current destination writes nothing.

To select a remote without the picker:

```bash theme={null}
entire enable --yes --checkpoint-push-remote fork
```

The remote must already exist. Use the same command to change the destination later, or to repair a saved selection that names a missing remote. An explicit flag pins the named remote, even if it is currently selected automatically. `--yes` alone does not change the destination.

Selecting a destination does not re-enable disabled checkpoint pushing, upload existing checkpoints immediately, or move or delete checkpoint history on other remotes.

## Edge Cases

* An SSH host alias from `~/.ssh/config`, such as `git@github-work:acme/widgets.git`, counts as GitHub when Git runs plain `ssh`. With a custom `GIT_SSH_COMMAND` or `core.sshCommand`, the alias cannot be resolved, so it does not match.
* `entire enable` always says where checkpoints will be uploaded. When you chose the destination, it also says how. If a saved destination is unusable, it reports the problem instead of showing the privacy notice, unless checkpoints still upload to a dedicated checkpoint repository.