entireio / entireio/cli

Checkpoint remote migration falls back to origin and loses transcript data after switching to external repo

Open
#1,139 6 comments 0 reactions 0 assignees View on GitHub

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

  1. Updated and committed .entire/settings.json on the default branch:
{
  "enabled": true,
  "log_level": "DEBUG",
  "strategy_options": {
    "checkpoint_remote": {
      "provider": "github",
      "repo": "SvenMeyer/Infrafund-front-pro-entire"
    }
  },
  "telemetry": true
}
  1. Logged out of the current session.
  2. 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>`.
  1. Started a fresh Droid CLI session.
  2. Had the agent create a commit and push.

Expected behavior

  • Entire should push entire/checkpoints/v1 to SvenMeyer/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/v1 to origin
  • The configured external checkpoint repo did not receive the new checkpoint updates
  • In the Entire web dashboard, commit 98b6a7d showed: 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

  1. Is migrating an existing repo from internal/default checkpoint storage to checkpoint_remote after the fact supposed to work?
  2. Is the owner-mismatch fallback intended even for an explicitly configured private checkpoint repo?
  3. Is there a supported migration/re-indexing step required so transcript metadata remains linked after switching remotes?
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.