The Entire CLI: How It Works & Where It's Headed
"I don't even read the code my agents produce" is the ultimate developer flex of 2026.
But it is really a coping mechanism. There is simply too much code to review. Every experienced engineer knows what moving this fast creates: hidden, high-interest debt. That's fine for a weekend, vibe-coded project. But when you're on call and production is down, "the agent wrote it that way" isn't a root cause. Without a time machine, you're debugging a black box.
In traditional engineering, git commits served us well. They show us what changed. But both at the speed of AI and for team coherence, that's no longer enough. We need to understand the why.
What prompt was given? What was the chain of agents and subagents that produced this? What alternatives were tried and discarded? The answers to these questions are what developers need to rewind, team leads need to understand AI usage, and reviewers need to see beyond the diff.
Checkpoints are our initial answer.
A richer primitive than commits, capturing not just what changed, but the context behind it.
What's a Checkpoint?
A Checkpoint is a single, addressable unit that bundles everything behind a change: the code state, the agent's full transcript, your prompts, token usage, and line-level attribution showing how much the agent wrote versus what you edited. Each Checkpoint gets a 12-character ID, stored in git and included in your commit via a trailer, so you can trace any change back to the exact session that produced it.
When Checkpoints are pushed to a shared remote, anyone can see how AI and a human built a feature together, not just what changed.
How it works
Developers are already accustomed to working with an agent and committing code, and we didn't want to disrupt that existing developer experience. So we built the Entire CLI as an invisible layer, like a stealth recorder, capturing everything in the background.
That led to one strict constraint: everything had to fit inside a normal git workflow, from capturing sessions to storing metadata and linking it to commits. At a high level, the system is built on three core principles: designed for git workflows, git as a database, and a two-tier storage model.
Designed for Git Workflows
Entire fits into your existing git workflow without changing how you work.
Because the Checkpoint ID is stored in a commit trailer and not tied to a commit hash, it survives commonly used git operations that rewrite commit history, like rebase, amend, squash, and cherry-pick. Instead of breaking when commits are rewritten, the link between your code and its session history remains intact.
That same separation extends to how the data is stored. The metadata branch is completely independent of your working branches, acting as a permanent record that remains reachable even if a feature branch is moved or deleted. Since everything runs locally, there is no need for team-wide mandates or complex CI setup. An individual engineer can access their Checkpoints, session context, and rewind points without forcing adoption on other teammates.
Git as a Database
Everything Entire records, transcripts, prompts, attribution, summaries, is stored as git objects. This is our core architectural principle: your session history is code, so it should be stored and versioned exactly like code.
Depending on your team's workflow, you can choose where those objects live:
Same repository By default, Checkpoint metadata lives on a separate branch called entire/checkpoints/v1 that travels with your repository. When you push your code, your session history goes with it. When someone clones the repo, they get the full context too.
Decoupled repository For teams that need more control, Checkpoints can be stored in a separate repository. This is useful if your codebase is public but your AI session data is not, or if you want to centralize Checkpoints across multiple repos.
This approach is valuable for a few reasons:
- It builds on existing git infrastructure instead of introducing a new database, SaaS product, or proprietary storage layer.
- Because session history lives in git, it moves with the workflow across different hosts, during offline work, or when switching remotes.
- Every change to session history is tracked, providing the same auditability and rollback capabilities expected from git.
Two-tier Storage Model
We use a two-tier storage model for temporary and permanent Checkpoints.
You need the ability to rewind mid-session if an agent goes sideways, so we provide Checkpoints before you commit. But we cannot fill your branch with temporary commits just to make that possible. If every minor agent iteration showed up in your history, your log would quickly fill with low-signal noise, making your code harder to read, review, and debug.
To avoid that, the Entire CLI writes those Checkpoints to shadow branches. Shadow branches are temporary, out-of-band branches that store Checkpoint data while you work. They follow a specific naming convention: entire/<commit-hash-7-chars>-<worktree-hash-6-chars>, and stay completely separate from your working branch. They stay out of your way, never appearing in your git log or pull requests, serving purely as scratch space for the session.
Once you commit, that temporary state is condensed into a permanent record, with transcripts, prompts, file changes, token usage, and attribution written to a dedicated Checkpoints branch and linked to your commit via a trailer.
While the principles stayed the same, the implementation had to evolve.
What's Changed Since Launch
When we launched Entire, we had a simple mental model: a hook fires, data is captured, the user commits, done. That worked for single-agent, single-session workflows.
Real-world engineering isn't linear. You rebase mid-session, you stash changes, and you often run multiple agents at once. To handle this, we moved away from simple hooks and formalized how sessions behave. Sessions are now treated as a state machine with explicit phases (IDLE, ACTIVE, ENDED) managed in .git/entire-sessions/.
This architectural shift unlocked the following features:
- Concurrent sessions: You can run two agents in the same repository at the same time. For example, a Claude Code session in one terminal and Cursor in another, each tracked independently.
- Interrupted workflows: You can rebase or stash mid-session without losing Checkpoints.
- Line-level attribution: Every Checkpoint tracks which lines of code came from the agent versus which came from you.
- Subagent tracking: When an agent spawns a subagent, it receives its own nested Checkpoint. This preserves the full chain of command so you can see exactly how a high-level goal was decomposed into smaller agentic actions.
- Multi-agent support: Entire is agent-agnostic, supporting Claude Code, Cursor, Gemini CLI, GitHub Copilot CLI, Factory AI Droid, OpenCode, and external agent protocols.
- Separate checkpoint repository: You now have the choice to store Checkpoint data in a separate repository from your main code. This is useful when your codebase is public but your AI session data is not, or when teams want to centralize checkpoint data across multiple repos.
Where We're Headed
Now that we've turned raw developer activity into structured, reliable data, the Checkpoint becomes a new semantic unit, richer than commits, queryable, and shareable.
From here, we start to build toward team visibility, search, auditability, and a different way to think about code review.
Team Visibility
Git tells you who committed the code. Entire shows how it was built, recording token usage, agent type, and attribution directly in the repository so the invisible parts of development become a shared signal.
When a feature ships with 90% agent-generated code, that context will help the whole team. The author gets better feedback, reviewers know where to focus, and the next person to touch that code knows what they're walking into.
Search
Traditional git log answers "what changed," but in today's workflows a more pressing question is "why did we do it this way?"
We're making that answer searchable. Users will be able to surface the prompt that introduced a workaround or revisit the reasoning behind a library choice months later. The "why" will be part of your history.
Audit and Transparency
In regulated industries like finance, healthcare, and defense, "who wrote this code" has direct implications for compliance, liability, and safety. The Entire CLI will solve this by capturing accurate attribution and authorship at commit time. By mapping every step from human prompt to agent response to final human refinement, it makes clear what part the human played versus the agent.
Rethinking Code Review to Intent Review
Code review was built for a human pace. But with agents shipping entire features in a single session, reviewers are drowning in massive diffs and defaulting to approving with a measly "LGTM." The issue is already so prevalent that some open source maintainers are banning agent-authored contributions.
Checkpoints are the foundation, but the next step is a shift in methodology. We are moving beyond the diff to replace code reviews with intent reviews. This positions reviewers to start with intent by examining the prompt, the session transcript, and the reasoning behind key decisions. Instead of parsing 500 lines of syntax, they focus on the problem being solved and whether the right calls were made along the way.
At Entire, we're actively building the world's next developer platform in the open. If you're experimenting with agents, join the Discord, share what you're seeing, and help shape where this goes next.