Is Entire.io entirely hype or is it the future of GitHub?

Entire.io has been making headlines in the startup space. But, all the pieces I've read have been focused on who the founder is and how much money he has raised so far. I want to look through the hype and actually try out what they're currently offering. If it's any good, it could be a glimpse at the flow of software development in the future.

Entire's first product is Checkpoints, which is an open-source CLI that is said to act as an observability layer between your AI coding agent and Git. Its premise is quite simple: for every Git commit that you make, all the current context of your agent is saved alongside any code changes. This should make it easier for a developer to understand where and why an agent went off course.

I set it up with Claude Code and built a project from scratch to test it out.

What is Entire?

Here's the bit about the CEO and the money: Entire was founded by Thomas Dohmke, the former CEO of GitHub. It launched in February 2026 with a $60M seed round.

They have several projects in their pipeline but only Checkpoints is publicly available so far.

Now that I've read more about their plans, I get the impression that Dohmke is not seeking to build a GitHub competitor (which was my early impression), but rather a full abstraction layer that sits on top of GitHub. If this is realized, in practice it will mean that developers will no longer interact with GitHub directly. No manual pull requests or review flows. Rather, your agent will handle the technicalities and developers will have a higher-level view where they can explore changes with the full context of all the agents and humans that contributed to the code.

This sounds appealing to me as I've always found GitHub to be finicky and, lately, have been interacting with it through agents almost exclusively.

Setting it up

Checkpoints is very easy to get started with, and this gave me the immediate impression that I was working with well-crafted software.

Install Entire through Homebrew:

brew install entireio/tap/entire

Then initialize a Git repo:

mkdir my-project && cd my-project
git init && git commit --allow-empty -m "Initial commit"

Finally, enable Entire:

entire enable

Entire asks which agent you're using and sets everything up. Run entire status to confirm it's tracking:

● Enabled · manual-commit · branch main

That's it. Effectively, adding two steps to the normal Git flow. From this point, Entire automatically tracks any Claude Code session launched from this directory.

One thing to note: Because the hooks live in the project's .claude/settings.json, Entire tracks only the agent sessions launched from this directory. An agent running from another directory could still commit to the repo, but Entire wouldn't capture the conversation.

What it installs behind the scenes

Running entire enable creates two things. First, it creates a .claude/settings.json file with hooks that tap into Claude Code's event system:

• SessionStart and SessionEnd capture when a session begins and ends
• UserPromptSubmit captures every prompt you send
• Stop captures when the agent finishes responding
• PreToolUse and PostToolUse capture task and tool activity

Second, it creates a Git post-commit hook that condenses session data whenever you commit.

The agent doesn't know it's being observed. Entire listens to events that Claude Code already emits.

Building a project under observation

To test Entire, I had a Claude Code agent build a conspiracy theory generator API "Tinfoil", using FastAPI. The project went through four iterations:

1. A basic API with hardcoded Mad-Libs-style theory generation
2. A refactor to async SQLite with rate limiting and error handling
3. A conspiracy-themed web frontend
4. LLM-powered generation with OpenAI, user auth, WebSocket, and a dark- and light-mode toggle

I made each commit more complex than the last to try and get the agent to do something weird for me to explore in the context history.

So I committed each iteration separately and Entire captured a checkpoint for each one. Running entire status at any point showed the active session:

● Enabled · manual-commit · branch main

── Active Sessions ─────────────────────────────────────────

Claude Code (claude-opus-4-6[1m]) · f5d1ab82-c2ea-46e9-ad1f-692fdd7277e3
> "Build me a FastAPI app called "Tinfoil" — a Conspiracy Th..."
started 10m ago · active now · tokens 41.8k

────────────────────────────────────────────────────────────
1 session

Entire tracks the session in real time, recording the model, opening prompt, token count, and how long it's been running. The data accumulates on a separate Git branch (entire/checkpoints/v1) and on shadow branches, keeping your main branch clean.

After four iterations, the finished app (built solely by a Claude Code agent tracked by Entire) looked like this:

What the checkpoint data actually looks like

After the first commit, I checked what Entire stored on the checkpoint branch:

git ls-tree -r --name-only entire/checkpoints/v1

And found the following structure:

34/2e4553316e/0/content_hash.txt
34/2e4553316e/0/full.jsonl
34/2e4553316e/0/metadata.json
34/2e4553316e/0/prompt.txt
34/2e4553316e/metadata.json

Each checkpoint gets its own directory with four files. The metadata.json file contains the most immediately useful information:

{
    "agent": "Claude Code",
    "model": "claude-opus-4-6[1m]",
    "files_touched": ["README.md", "main.py", "requirements.txt"],
    "token_usage": {
        "input_tokens": 8,
        "cache_creation_tokens": 10247,
        "cache_read_tokens": 93397,
        "output_tokens": 2900,
        "api_call_count": 5
    },
    "initial_attribution": {
        "agent_lines": 174,
        "human_added": 0,
        "human_modified": 0,
        "total_committed": 174,
        "agent_percentage": 100
    }
}

The attribution tracking is interesting: 174 lines, 100% agent-written, zero human modifications. This is per-commit, so you can see exactly how much of each change was agent vs human.

The prompt.txt file contains the verbatim prompt that started the session. The full.jsonl file contains the most useful data, including a line-by-line record of every message, tool call, and response in the session. For the first commit (a straightforward API scaffold), this was 49 KB. By the fourth commit (with LLM integration, auth, and WebSocket), it had grown to 1.2 MB across 50 API calls. The total .git directory went from 280 KB to 1.5 MB over four commits. Not alarming for a small project, but worth keeping in mind for long-running repos.

What a "simple" bug fix looks like in the checkpoint data

This is where I first thought "Huh, that's pretty useful". After the fourth commit, I asked the agent to do something mundane:

Create an account for me in the app we've made with username: Lewis and password: password!

Bugs in this process resulted in a bunch of side effect changes. And I ended up with the following commit message:

Fix dotenv import and replace passlib with bcrypt directly

passlib is unmaintained and incompatible with newer bcrypt versions,
causing a crash on registration. Use bcrypt directly instead. Also
fix dotenv import to use the correct module path.

Claude Code changed six lines across three files. From the Git history, it looks like someone noticed two bugs and fixed them. But the checkpoint data tells a different story:

The prompt.txt showed the full prompt that started the session. The agent tried to hit the register endpoint, but the server wouldn't start. The full.jsonl records three failed server startup attempts, each with different error traces. The agent diagnosed that passlib was unmaintained and incompatible with the installed version of bcrypt, swapped it for direct bcrypt calls, then found a separate dotenv import bug and fixed that too.

The metadata indicates the scale of this change: 80 API calls and 15 turns, although there were only six lines of actual code changes. The commit doesn't mention account creation at all.

I'm now imagining a scenario where this is a shared code base and a co-developer comes up to me asking why I decided to rewire the auth stack. Confused, I tell them that I did no such thing. Now, we can look at the checkpoint data and see that my account creation ambitions led the agent on a small debugging rampage.

This is the strongest case for Entire's value. Entire bridges the gap between what Git records ("fixed two bugs") and what actually happened ("tried to create an account, server crashed three times, discovered an unmaintained dependency, rewired the auth stack").

What leaks into checkpoints

Entire claims "best-effort" secret redaction. I wanted to see what that means in practice, so I checked the checkpoint data for sensitive information.

Environment variable names like OPENAI_API_KEY and ANTHROPIC_API_KEY appeared 78 times in the transcript. That's expected, because the agent was writing code that referenced them. The actual key values from the .env file did not appear in the transcript or the checkpoint branch. So far, so good.

The shadow branch is a different story. Entire creates shadow branches (like entire/4325886-e3b0c4) that snapshot the working directory.

I checked what was on the shadow branch by running the following command:

git show entire/4325886-e3b0c4:.env

And it returned this output:

OPENAI_API_KEY=sk-proj-i9So-FlBfCls...

The full API key, in plaintext, is on a Git branch, even though .env is in .gitignore. The shadow branch bypasses .gitignore when capturing snapshots. If you push the Entire branches to a remote, your secrets go with them.

Passwords entered in prompts are also captured verbatim. The initial account creation prompt (with username: Lewis and password: password!) showed up in both prompt.txt and in the agent's curl command inside full.jsonl. On the next commit, this landed on the checkpoint branch.

So, be careful about pushing Entire's branches to shared remotes. The checkpoint branch and shadow branches contain more than your main branch's .gitignore would suggest.

Testing rewind

Entire's rewind feature is pitched as a way to roll back when an agent goes off track. Running entire rewind opens an interactive picker showing your checkpoints:

entire rewind

I selected the Add conspiracy-themed web frontend checkpoint to roll back past the LLM integration. The code on disk reverted, and the login button, light mode toggle, and auth files all disappeared. The app went from the full version shown earlier back to this:

Running claude --continue after the rewind picked up the agent's session with context that matched the rolled-back code. The key difference from a plain git reset is that Entire synchronizes the code and the agent's memory, so the agent knows where it is.

However, Entire's rewind feature is one-directional. After rewinding, entire rewind only shows the older checkpoints. The newer commits disappear from the list. The data isn't lost, because the checkpoint branch retains everything, but there's no "redo" command.

I found a recovery flow that works but isn't documented:

1. Run git reflog to find the commit hash you want to restore.
2. Run git reset --hard <hash> to get the code back.
3. Run entire rewind --to <hash> and choose restore logs only to sync the agent's context.
4. Run claude --continue, so that the agent now has the correct context matching the code.

Without Step 3, claude --continue thinks it's still at the rewound state and sees the restored code as uncommitted changes made outside the session. The extra entire rewind --to command with restore logs only is what reconnects the context.

Handing off a session

Another function of storing checkpoint data is the ability to hand off work to a coworker. The full Claude context is saved alongside the code, so a coworker (or even a stranger on a public repo) can clone the repo and pick up where the previous developer's agent left off.

I tested this by pushing the Tinfoil project to a remote GitHub repository and cloning it to a separate directory.

Then, all I needed to do was run:

entire resume main

And Entire restored the session log from the checkpoint data.

After restoring a session log, you can run the following command, and Claude will pick up the full prior context:

claude --continue

The agent summarizes what happened in the previous session and continues where the previous agent left off.

Wrapping up

I was skeptical of Entire due to the media focus on the CEO's history and the amount of money they are raising, while struggling to find any impressions of people using the product.

But, I've been impressed with the UX of the Checkpoints product and I think it is a simple and clever idea that was more useful than I expected. I think anyone using agents to code should install Entire and give it a try.

That being said, some of my skepticism of Entire as a whole remains. Now that the idea is out there, there's nothing to stop GitHub or other parties from implementing their own versions of it.

I hope to see Entire moving quickly to flesh out their full suite of products before Microsoft releases the new "industry standard" agent observability layer with a massive Enterprise price tag and free BSODs for all.