Checkpoint remote migration falls back to origin and loses transcript data after switching to external repo
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 5.1k
- Forks
- 475
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 178
Description
Summary
After starting with the default/internal Entire checkpoint storage and later switching this repo to a private checkpoint remote, Entire still pushed entire/checkpoints/v1 to origin instead of the configured external repo. After that, a new commit/checkpoint (98b6a7d) appeared in the web UI with Transcript data is unavailable for this checkpoint.
Motivation
Per the docs, it should be possible to configure a checkpoint remote in .entire/settings.json / entire enable --checkpoint-remote ... and have Entire push checkpoint data there. We changed strategy later in the lifecycle of an existing repo/session setup, and expected that to work without losing transcript linkage.
Docs referenced: https://docs.entire.io/cli/checkpoints#checkpoint-remote
Environment
- Entire CLI:
0.6.0 (0ec0d032) - OS: Linux (Manjaro),
linux/amd64 - Main repo: private GitHub repo under a different owner/org than the checkpoint repo
- Main repo default branch:
develop - Main repo remote owner:
InfraFund-net7/front-pro - Checkpoint repo:
SvenMeyer/Infrafund-front-pro-entire(private)
Initial state
We originally used the default/internal checkpoint setup.
Later we decided to move checkpoints to a separate private repo as described in the docs.
What we changed
- Updated and committed
.entire/settings.jsonon the default branch:
{
"enabled": true,
"log_level": "DEBUG",
"strategy_options": {
"checkpoint_remote": {
"provider": "github",
"repo": "SvenMeyer/Infrafund-front-pro-entire"
}
},
"telemetry": true
}
- Logged out of the current session.
- Ran:
entire enable --checkpoint-remote github:SvenMeyer/Infrafund-front-pro-entire
CLI output:
✓ Settings updated (.entire/settings.json)
Agents: Claude Code, Copilot CLI, Cursor, Factory AI Droid, Gemini CLI, OpenCode
To add more agents, run `entire agent add <name>`.
- Started a fresh Droid CLI session.
- Had the agent create a commit and push.
Expected behavior
- Entire should push
entire/checkpoints/v1toSvenMeyer/Infrafund-front-pro-entire - The new checkpoint/commit should keep its transcript linkage in the Entire web UI
- Migrating from previous/internal storage to a checkpoint remote later should be supported or at least fail with a clear warning if not supported
Actual behavior
- Entire still pushed
entire/checkpoints/v1toorigin - The configured external checkpoint repo did not receive the new checkpoint updates
- In the Entire web dashboard, commit
98b6a7dshowed:Transcript data is unavailable for this checkpoint.
Evidence
Current config:
{
"enabled": true,
"log_level": "DEBUG",
"strategy_options": {
"checkpoint_remote": {
"provider": "github",
"repo": "SvenMeyer/Infrafund-front-pro-entire"
}
},
"telemetry": true
}
Refs after reproducing:
origin entire/checkpoints/v1:
52e1a472c3ae173f7382e86f73743681f308b40c
external repo entire/checkpoints/v1:
0f6e1e15f322abbfe359bec8e468b67c6b5ac35d
So the checkpoint branch advanced on origin, but not on the configured external repo.
The docs mention fork detection and say that if the push remote owner differs from the checkpoint remote owner, checkpoints may fall back to the fork/origin remote. If that behavior is expected here, then there seems to be a mismatch between:
- wanting to use a private external checkpoint repo under another owner/org, and
- the current fallback behavior
Also, even if fallback is expected, I would not expect transcript linkage for the new checkpoint to become unavailable.
Questions
- Is migrating an existing repo from internal/default checkpoint storage to
checkpoint_remoteafter the fact supposed to work? - Is the owner-mismatch fallback intended even for an explicitly configured private checkpoint repo?
- Is there a supported migration/re-indexing step required so transcript metadata remains linked after switching remotes?
- Could the fallback behavior be surfaced more explicitly in CLI output when this configuration is ignored/skipped?
Happy to provide more logs or test a patched build.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the migration with .entire/settings.json and entire enable --checkpoint-remote github:SvenMeyer/Infrafund-front-pro-entire, then trace how the checkpoint remote is selected when the repository owners differ. Compare pushes to origin and the configured repository, and inspect how checkpoint 98b6a7d is linked to transcript data. Done means the configured remote is honored or the CLI clearly reports the fallback, without losing transcript linkage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100