Entire.io Hands-On: What It Actually Captures When AI Agents Write Your Code

Git tracks what changed in your code but not how it got there. It doesn't capture the prompts that produced those changes, the approaches the agent tried and abandoned, or how many tokens it burned along the way. When you're reviewing agent-generated code, the diff tells you almost nothing about how it was made.

Entire is a CLI tool that tries to fix this. It hooks into agents like Claude Code and captures every prompt, response, and tool call alongside your commits. It tracks how much code was written by an agent vs a human. And it offers a rewind feature that rolls back both your code and the agent's context together.

I set it up with Claude Code and built a project from scratch to test these claims. I found the reasoning capture worked well, and the attribution tracking was straightforward, but the rewind feature was more nuanced than the docs suggest.

What is Entire?

Entire was founded by Thomas Dohmke, the former CEO of GitHub. It launched in February 2026 with a $60M seed round. The company's first product was Checkpoints, an open-source CLI written in Go that acts as an observability layer between your AI coding agent and Git. It currently supports Claude Code, Gemini CLI, OpenCode, Cursor, Factory AI Droid, and GitHub Copilot CLI, though most of those are still in preview. I tested with Claude Code, which has full support.

Setting it up

Install Entire through Homebrew:

brew install entireio/tap/entire

Then initialize a Git repo and enable Entire:

mkdir my-project && cd my-project
git init && git commit --allow-empty -m "Initial commit"
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

From this point, Entire automatically tracks any Claude Code session launched from this directory.

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. 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.

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

Each iteration was committed 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

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 Entire justified itself for me. 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!
``

The resulting commit looked like a clean, focused bug fix:

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. Without the checkpoint data, there's no way to know what triggered this fix or how much debugging went into it.

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:

![Tinfoil after rewinding](/img/guides/entire-io-hands-on/tinfoil-before-rewind.png)

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 valuable Entire feature provides 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

The reasoning capture is the strongest part of Entire. Seeing the full story behind a commit is useful. The attribution tracking (showing agent vs human lines per commit) is a nice bonus for teams thinking about code review workflows.

The rewind feature is useful when an agent goes down the wrong path. Rolling back the code and the agent's context together means you don't end up with an agent that's confused about the state of the project.

The security story needs attention. Shadow branches bypass `.gitignore`, and everything typed into a prompt ends up in the checkpoint data. If you're pushing Entire's branches to a shared remote, treat them with the same care as any other sensitive data.

Entire is still in early development. Five of the six supported agents are in preview, and the broader platform vision (a custom database and UI layer) hasn't shipped yet. But for what it does today, capturing the context that Git misses, it fills a real gap. If you're doing code review on agent-generated PRs, handing off work between developers, or just want to understand what actually happened during a session, it's worth trying.