remote checkpoint broken

[rublev]

What happened?

I want conversations to go to a different repo, never my working repo. I have this:

{
  "enabled": true,
  "strategy": "manual-commit",
  "strategy_options": {
    "checkpoint_remote": {
      "provider": "github",
      "repo": "org/repo"
    },
    "push_sessions": false,
    "summarize": {
      "enabled": true
    }
  },
  "telemetry": false
}

I've tried some variations of push_sessions to true, removing push_sessions entirely, etc. Disabled and cleared the projects .entire as well and deleted the branches and tried to re-initialize but for the life of me I cannot get entire to push to a remote checkpoint.

I also don't notice any summaries or what to look out for to see if the summaries are working, but I don't see anything that screams "this is a summary" to me in the UI

Steps to reproduce

No response

Entire CLI version

Entire CLI 0.5.1 (d46fdc2)

OS and architecture

Darwin 24.6.0 arm64

Agent

2.1.87 (Claude Code)

Terminal

iTerm2 Build 3.6.9

Logs / debug output

Additional context

No response

[rublev]

FIX ITTTTTTTTTTT

[blackgirlbytes]

Confirmed that I was able to reproduce this problem as well.

When checkpoint_remote is configured in .entire/settings.json, checkpoints are supposed to be pushed to the specified
 remote repo instead of origin. However, if the owner of the origin remote differs from the owner in
 checkpoint_remote.repo, fork detection silently skips the checkpoint remote and pushes to origin instead.

repro steps:

1. Clone a repo owned by a different org/user than your checkpoint remote:
   gh repo clone some-org/some-repo
   cd some-repo
   entire enable 2. setup remote checkpoint to a repo that is under your org/user
2. start agent session..create checkpoints. you will notice the checkpoints go to the wrong repo.

[blackgirlbytes]

okay so I dug into this with a few engineers..and it looks like they set it up this way by design. The CLI has fork detection that compares the owner of your origin remote to the owner in your checkpoint_remote config. If they don't match, it silently skips the checkpoint remote and pushes to origin instead. So if your origin is some-org/repo but your checkpoint_remote points to addy/private-checkpoints, the CLI sees the owner mismatch and ignores your config with no warning.
If an org commits checkpoint_remote in their shared .entire/settings.json and someone forks the repo, you don't want the fork accidentally pushing checkpoints to the org's checkpoint repo, so that's why we built it this way.

But we also recognize that your scenario is a bug..and we're working on a fix

[rublev]

okay so I dug into this with a few engineers..and it looks like they set it up this way by design. The CLI has fork detection that compares the owner of your origin remote to the owner in your checkpoint_remote config. If they don't match, it silently skips the checkpoint remote and pushes to origin instead. So if your origin is some-org/repo but your checkpoint_remote points to addy/private-checkpoints, the CLI sees the owner mismatch and ignores your config with no warning. If an org commits checkpoint_remote in their shared .entire/settings.json and someone forks the repo, you don't want the fork accidentally pushing checkpoints to the org's checkpoint repo, so that's why we built it this way.

But we also recognize that your scenario is a bug..and we're working on a fix

right on! thank you for looking into this. so i'd just have to have my repo in the same place as the org conversation repo, or have a separate private repo for conversations under my user as well my repo under my user? so either rublev/repo-convos + rublev/repo or org/repo-convos + org/repo