Using Entire CLI with Public Repositories: A Private/Public Dual-Remote Configuration

Introduction

In my previous review article, I organized the current state of Entire CLI and wrote that "it is better to avoid introducing it in public repositories."

However, by being creative with the Git remote configuration, there is a way to enjoy the benefits of Entire even in public repositories while avoiding the risk of exposing session logs.

In this article, I will introduce that method.

This article is the 4th in the Entire CLI series.

1. Conflict issues with husky
2. How to run it on Claude Code Web
3. Review of Entire.io
4. This article — Operating method in public repositories

The Problem: Using Entire in public repos makes session logs visible to everyone

Entire saves session transcripts (prompts, reasoning processes, tool calls) to a branch named entire/checkpoints/v1. This branch is independent of the code's main branch but exists within the same repository.

In other words, if the repository is public, the session logs will also be public.

The official README also contains a warning:

Your session transcripts are stored in your git repository on the entire/checkpoints/v1 branch. If your repository is public, this data is visible to anyone.

The official solution is to "kill the features"

Entire CLI has an option called --skip-push-sessions.

entire enable --skip-push-sessions

This stops the pushing of the checkpoint branch. However, if you don't push it:

• You cannot view sessions in the entire.io web viewer.
• You cannot rewind using entire rewind from other machines or sessions.
• You cannot share session information with team members.

Most of Entire's value is lost. It's equivalent to saying "don't use it."

The Third Option: Separate the remotes

The idea is simple. Save Entire's data to a private repo and push only the deliverables to the public repo.

Daily work (git push) goes to the private repo. Entire's checkpoints are also stored here. When you want to publish, a git push public main will reflect only the main branch to the public repo.

Procedure

1. Create a private repo for work

Create a new private repository on GitHub. You can name it anything, but making it clear which public repo it corresponds to makes management easier.

Example: If the public repo is myname/myproject, you could make the private repo myname/myproject-dev.

Keep the repository empty (do not create a README or .gitignore).

2. Swap the local remotes

Rename the existing origin (the public repo) to public, and make the new private repo the new origin.

# Rename the existing origin to public
git remote rename origin public

# Add the private repo as origin
git remote add origin [e-mail]:myname/myproject-dev.git

# Push to the private repo
git push -u origin main

Operational reason for making origin private
In a typical Git setup (push.default = simple), a git push without arguments goes to the tracking branch, which is origin (the private repo here).

By making this most frequent command point to the private repo by default, you create a state where "simply running git push without thinking saves both the code and Entire's session logs to a safe place." This is a safety measure to prevent accidental log exposure due to muscle memory.

3. Enable Entire

entire enable --agent claude-code

The standard procedure is fine. Hooks will be placed in .git/hooks/.

4. Modify the pre-push hook

Edit the .git/hooks/pre-push file placed by entire enable to modify it so that Entire only executes during pushes to origin (private).

Before modification (generated by entire enable)

#!/bin/sh
# Entire CLI hooks
# Pre-push hook: push session logs alongside user's push
entire hooks git pre-push "$1" || true

After modification

#!/bin/sh
# Entire CLI hooks
# Pre-push hook: push session logs alongside user's push
# Only run entire for origin (private repo); skip for public remote
if [ "$1" = "origin" ]; then
  entire hooks git pre-push "$1" || true
fi

$1 is passed the name of the remote being pushed to. By skipping the Entire hook when pushing to the public remote, you prevent the checkpoint branch from being pushed to the public repository.

5. Workflow

# Regular work: Push to the private repo (Entire checkpoints are saved alongside)
git push

# Publishing: Push only the main branch to the public repo
git push public main

Since git push public main specifies only the main branch, entire/checkpoints/v1 will not be pushed.

Important Considerations

Re-running entire enable overwrites the hook

If you re-run entire enable after an update to Entire CLI, .git/hooks/pre-push will be reset to its initial state. You will need to redo the modification in step 4.

As a countermeasure, it's a good idea to keep a copy of the modified hook content somewhere or script the modification procedure.

Do not run git push public without a refspec

Running git push public (without specifying a branch) might push all branches depending on your Git configuration. Always specify the branch clearly with git push public main.

If you are concerned, check your push.default setting.

git config push.default

If it is simple or current, it is relatively safe as only the current branch will be pushed, but it is always better to be explicit.

Manage files you only want in private using .gitignore

Since both repositories share the same main branch, any committed files will be reflected in public when you run git push public main. Add any files you want to keep only in the private repo (such as local configuration notes) to .gitignore.

Conditions that this configuration can solve

I'll repost the conditions for introducing Entire that I presented in my previous review article.

Condition	Reason
Must be a private repository	Avoiding the risk of transcript exposure
Used in a small team (1–3 people)	Avoiding concurrent session bugs and metadata bloat
Do not use squash merge	Avoiding broken checkpoint links
Not using LFS	Avoiding performance issues
Development is primarily in English	Avoiding CJK character corruption bugs
Operating rules prohibit secrets in prompts	Mitigating the risk of secret leakage
Can be accepted as an "experimental tool"	Being prepared for critical bugs like git config corruption

This private/public dual-remote configuration solves two points: "Must be a private repository (transcript exposure risk)" and the accompanying "Operating rules prohibit secrets in prompts (secret leakage risk)."

The biggest blocker—session logs being disclosed to the internet—can be avoided, and even if a secret happens to slip into a prompt, it won't leak to the public repository. However, the specification where data is sent to the Entire web dashboard side remains unchanged, so it's still desirable to follow an operation that avoids including secrets as much as possible.

On the other hand, issues inherent to the CLI itself (such as broken attribution calculations and Japanese character corruption), performance delays, and specification challenges like broken links during squash merges still remain.

Therefore, even if you adopt this dual-remote configuration, its use is currently limited to "experimental use in personal or small-scale OSS projects, with an understanding of the risks."

Summary

In my previous review article, I wrote that "it should be avoided in public repositories," but that refers to introducing Entire directly into a public repo.

By preparing a private repo as a workspace and using the public repo as the destination for publishing deliverables, you can fully utilize Entire's session recording features while maintaining the cleanliness of the public repository.

If the quality of Entire improves and official support for public repos (such as the ability to finely control the push destination of the checkpoint branch) is added, this dual-remote configuration might become unnecessary, but for now, this is a realistic solution.