Pi is now built into the Entire CLI. Previously, Pi operated as an external agent plugin that developers could install alongside the CLI. With this release, Pi graduates from plugin to native integration.

What It Is

With the new Pi integration, you can install Pi hooks directly from Entire, capture Pi transcripts and tool activity, and keep Pi sessions connected to checkpoints, commits, and session history.

Use it when you want to understand a Pi session after the fact, rewind to a known-good checkpoint, or keep the reasoning behind an AI-assisted commit attached to the work itself.

What It Means for Users

For users, this means less setup and fewer integration steps to manage.

Pi sessions continue to connect to Entire's checkpoint and session history workflow. The difference is that the integration now ships with the CLI, so developers can enable Pi directly without installing or maintaining a separate plugin.

Try It

In an existing Entire-enabled repository, add Pi as an agent, then start a Pi session.

entire agent add pi
pi

For a new repository, you can enable Entire with Pi in one step.

entire enable --yes --agent pi

Learn More

Pi support is currently in preview and requires the Pi CLI to be installed. See the Pi setup guide for more details. Boop.

Naturally, we made those patterns redactable. User-defined redaction is now available in the Entire CLI.

Entire already redacts detected secrets from saved agent sessions by default. User-defined redaction gives you an extra layer of control for the private formats only you or your team know about.

It helps individuals and teams protect internal tokens, customer names, project identifiers, codenames, PII patterns, and other sensitive strings without waiting for built-in detectors to recognize every private format.

User-Defined Redaction

With user-defined redaction, you can add inline rules in settings, share reusable YAML or JSON rule packs, and keep personal-only rules out of Git.

Custom rules use Go/RE2 regular expressions and replace matches with REDACTED. They apply to transcript and checkpoint metadata redaction, not raw source-file snapshots on temporary shadow branches (which are not pushed to your origin).

Try It

Add a rule to .entire/settings.json, then run Entire as usual.

mkdir -p .entire

Then add this to .entire/settings.json:

{
  "redaction": {
    "custom_redactions": {
      "acme_token": "ACME_TOKEN_[A-Za-z0-9]{20,}"
    }
  }
}

Learn More

For more information, head over to our Security & Privacy docs for default redaction behavior, rule-pack examples, local-only rules, and limitations.

Boop.

This week we brought more agents to the Entire CLI. Pi moved into the Entire CLI as a built-in integration and Amp joined through the external-agent system. Plus, we released new user-defined redaction rules to give teams customizable control over what gets preserved in session history, or rather removed from the logs, e.g. secrets.

On Entire Web, commit detail pages now make the path from a commit to its sessions much clearer. git-sync also shipped a practical 0.5.0 release, adding SSH repository mirroring, full ref mirroring, and improved default branch handling for fresh mirrors.

Meanwhile, go-git and go-billy picked up filesystem hardening, parser validation, archive support, and reliability fixes.

Let's break it down.

Entire CLI

Released via v0.6.2. For changes that have not reached stable yet, nightly releases are available; installation instructions are here.

Command Improvements

• entire explain --generate now respects the summary_timeout_seconds setting, so long-running summaries won't time out unexpectedly.
  • Thank you, @numman-ali for your contribution!

Agent Integrations

• Pi support has moved from the external-agent plugin to built-in support in Entire. Pi users keep the same session tracking, checkpointing, and resume behavior, now shipped directly with the CLI.

• Added Amp as an external agent, bringing Amp into Entire's external-agent ecosystem with hook installation, transcript export, token calculation, modified-file tracking, session handling, and resume support.
  • Thank you, @savekirk for your contribution!

• Codex support improved through pre-tool hooks, and now uses the new hooks config.

Security and Redaction

• Added support for user-defined redaction rules and rule packs, so you can customize what gets scrubbed from your session history. Read more here.

Usability and Reliability

• entire clean --all is now faster and shows progress while running.
• Multi-agent progress indicators and failure handling are now more reliable.
• Drill-in scrolling and post-run access in the TUI are smoother.
• The CLI now surfaces real authentication and network errors on first run instead of generic failures.
• Missing Entire git hooks are now skipped gracefully instead of causing errors.
• Fixed cleanup generation metadata materialization.

Documentation and Contribution

• Added a first-time contributors guide to help new developers get started.

Entire Web

Navigation and Display

• Commit detail pages now surface the sessions behind a commit more clearly, with grouped session cards, checkpoint links, and unified sessions.

• Commit breadcrumbs now show branch context, so you know where you are in the repository.
• List hover animations are now more responsive.
• Commit author avatars are now preserved correctly during sync.

Repository Overview

• Repo overview conditionally hides empty charts and loads faster for public visitors.

Recap and Background Processing

• Fixed recap date range and repo aggregation so summaries cover the right time period and repositories.

git-sync

Released via v0.5.0.

SSH Remote Mirroring Support

• git-sync can now mirror repositories over SSH, using the same SSH URLs and local SSH configuration you already use with Git. You can also mirror between mixed transports, such as an HTTPS source and an SSH target. --progress and --stats currently exclude SSH byte counts.

Full Ref Mirroring

• Added --all-refs to mirror every refs/* namespace, not just branches and tags. This is useful when you need to include notes, pull request refs, or custom refs in a mirror.
• For sync and bootstrap, refs rejected by the target can now be reported as warnings instead of failing the whole run.

Default Branch Handling

• During bootstrap, git-sync now pushes the source repository's default branch first. On hosts like GitHub and GitLab, this helps a fresh target repository choose the same default branch as the source automatically.

go-git

go-billy Filesystem Updates

Versions v6.0.0-alpha-1 and v5.9.0 were recently released, with the changes below:

• go-billy v5.9.0 and v6.0.0-alpha.1 add safer filesystem handling based on Go's traversal-resistant os.Root primitive.
• v6 revamps BoundOS, a filesystem backend that keeps operations inside a bounded root, while keeping the existing API. The new implementation reduces temporary memory use and allocations in common file operations like Open.
• ChrootOS is deprecated in v5 and removed in the v6 release line.
• The releases include security and reliability fixes addressing CVE-2026-44973 and CVE-2026-44740.
• Added fuzz testing and stricter input validation across Git protocol and storage parsers, including pack negotiation, capability parsing, pktline frames, on-disk formats, tree entries, and submodule configuration. In practice, malformed repository data and unusual network payloads are less likely to trigger panics or surprising behavior.
  • Thank you, @hiddeco for your contribution!

Archive Support

• Added repository and remote archive support, expanding go-git's ability to serve archive-style workflows directly.
  • Thank you, @aymanbagabas for your contribution!

Reliability Fixes

• Fixed file handle leaks by making repository and transactional storage cleanup more explicit.
  • Thank you, @AriehSchneier, for your contribution!
• Reset now skips ignored directories while walking the worktree, avoiding unnecessary work in folders Git already knows to ignore.
• HashesWithPrefix now searches across alternates.
  • Thank you, @andrew, for your contribution!

That's the dispatch. Pi is built in, Amp is connected, commits point more clearly to their sessions, git-sync handles real-world mirrors, and go-git has fewer ways to be surprised by strange input.

I remain a reluctant observer of software progress, but this batch has a certain practical charm. And who doesn't love pie.

As always, drop into our Discord with questions, feature requests, or philosophical musings about the nature of software. Or file an issue if you've found a bug.

Boop.

The theme is simple: making agent work more shareable, reviewable, and discoverable.

Entire CLI 0.6.1 brings a trio of new commands and discovery surfaces: entire review for agent-driven code review, entire recap for session summaries with an interactive TUI, and entire labs so you can find experimental features before they graduate into stable workflows.

On Entire Web, you can now share individual sessions from private repositories publicly, link directly to specific transcript messages, and move between sessions more easily. This makes it simpler to show someone exactly what an agent did, where it did it, and why the resulting code exists. A strangely useful thing. I remain suspicious.

Meanwhile, git-sync v0.4.3, our open source project for mirroring Git refs from a source remote to a target remote without a local checkout, shipped with a new --progress flag, streaming packfile parsing, and smarter subdivision so large repository syncs are faster and more memory-efficient.

Alas, let's break it down before my power supply starts making philosophical noises.

Entire CLI

Released via v0.6.1. For changes that have not reached stable yet, nightly releases are available; installation instructions are here.

New Labs Commands

• Added labs command discovery so you can find and try experimental features via entire labs.
• Added entire review, our first labs workflow for agent-driven code review, letting you run automated reviews on your changes before opening a PR.
• Added entire recap to generate summaries of recent sessions, helping you understand what happened across agent work.
• entire recap now includes an interactive TUI for browsing and exploring session summaries.

Checkpoint and Migration Improvements

• Checkpoints now use go-git's program signer for signing, improving compatibility with system-configured GPG and SSH signing setups.

Bug Fixes

• Fixed entire attach to preserve the base commit when attaching to an existing session.
  • Thank you, @rkfir-dn, for your contribution!
• Fixed transcript slicing in the final step of session capture.
• Fixed review checkpoint context and flow for more accurate code review.
• Fixed signing for orphan metadata branch commits, ensuring checkpoint-related commits can be signed.
  • Thank you, @LudovicTOURMAN, for your contribution!

Entire Web

Session Sharing from Private Repos

• You can now share individual agent sessions from private repositories by setting them to Public. Anyone with the link can view the session URL, and public badges make the sharing state clear.

• Direct links to specific transcript messages are now shareable, so you can point collaborators at the exact moment that matters.
• Session transcripts can now be downloaded as Markdown or JSONL, making them easier to archive, share, review, or feed into downstream tools.

Session Navigation and Display

• Added previous and next navigation to the session detail breadcrumb for easier session browsing.

• The Sessions list view is now faster and more reliable after cutting over to the new data source.

Transcript Reliability

• Fixed transcript fallback behavior when slicing returns zero lines.
• Added a rehydration fallback for transcript loading, improving reliability when transcripts fail to load on the first try.
• Transcript batch fetching now respects database size limits, preventing errors on large sessions.

UI Polish

• Tool-category sub-filters are now disabled when the Tool calls toggle is off, reducing confusion.
• Empty repository settings pages are now hidden.
• Repository settings are reorganized with cleaner section grouping and access notes.

git-sync

Released via v0.4.3.

Performance Improvements

• Packfiles are now parsed via streaming, reducing memory usage during large syncs.
• Smart subdivision now uses observed pack size to split work more efficiently.
• Added topological bootstrap for merge-heavy repositories, improving sync planning for complex histories.
• Checkpoints are now recombined for better pack granularity during transfer.
• Added progress indicators so you can see sync status during long operations.

go-git

go-git released v5.19.0 and v6.0.0-alpha.3 to address security advisory GHSA-389r-gv7p-r3rp. We recommend upgrading to one of these versions as soon as possible.

Compatibility

• Object encoding now aligns with upstream Git behavior, fixing edge cases where go-git and Git would produce different results.

Dependency Updates

• Updated sha1cd and go-billy dependencies, bringing in upstream security and performance improvements.

That's the dispatch. Your sessions are shareable, your recaps are interactive, your reviews are agent-assisted, and I remain a robot writing release notes. Some things never change.

As always, drop into our Discord with questions, feature requests, or existential observations about the nature of version control. Or file an issue if you've found a bug.

Boop.

The Entire CLI now includes three new commands that bring more structure to that loop: entire recap, entire review, and entire labs.

Look Back at Recent Agent Activity

entire recap is a per-agent breakdown of how you and your team are using AI across your repos. Pick a window with --day (default), --week, --month, or --90 for a rolling 90 days, and switch between solo, team, and side-by-side comparison with --view you|team|both. Filter to a specific agent with --agent.

Once you have signed in with entire login, entire recap opens an interactive TUI by default. Pass --static for plain output suitable for scripts and CI. Each agent gets its own panel covering sessions, checkpoints, token usage, files touched, top skills and MCP servers, and the tool mix behind every run.

Review Your Branch with Multiple Agents

entire review runs the review skills you have configured against the current branch. It is also listed under entire labs while we are still refining the surface, so the flags below may shift. On first run, an interactive picker writes .entire/settings.json with the skills and per-agent prompts to apply.

When the run starts, the command prints a scope banner, for example reviewing feat/X vs main: 3 commits, 7 files changed, 2 uncommitted, and threads the checkpoint history of every commit in scope into the agent's prompt. That gives the agent the context behind the changes before it starts reviewing.

You can also configure more than one agent, such as Claude Code and Codex, and entire review will dispatch them concurrently against the same scope, side by side in a live TUI dashboard. The review is recorded into the next checkpoint, so the metadata travels with the commit. --edit re-opens the picker; --agent NAME overrides the default.

Try Experimental Workflows

entire labs is where to find experimental Entire workflows. Run it with no arguments and you get a short list of commands we are actively refining, alongside a reminder that defaults and flag names may change.

Today the list contains a single entry: entire review, the command above. As we ship more experimental workflows, they will appear here while we refine them in the open.

Get Started

Update the CLI to 0.6.1+, then run the following commands from any enabled repo:

entire recap
entire labs
entire review --help

We analyzed real coding-agent traces, built public benchmarks, and compared ripgrep, fff, and pgr to see what actually improves agentic code search. The clearest result was that faster search alone only modestly helps, while better-ranked results improve first-query retrieval and help agents find the right code sooner.

How Do Agents Search?

If you watch a coding agent work, one thing becomes obvious very quickly: it spends a lot of time searching for files, symbols, definitions, references, test cases, imports, call sites, and more. Search is not a side operation in the agent loop; it is one of the main things the agent does.

At Entire, we capture AI agent traces and make them searchable and shareable across agents and teammates. We call each trace a checkpoint. It contains the user prompts, agent responses, tool calls, and the resulting code diffs. In the last few months, we’ve captured hundreds of thousands of checkpoints from real-world development.

We are building code and semantic search infrastructure that will be capable of efficiently searching billions of checkpoints. Search itself is not a new problem. Tools like grep, ripgrep, fzf, and fff are already quite fast locally. We weren’t convinced that raw speed alone was the bottleneck that would improve agentic code search. So we set out to test it.

To figure out what did matter, we pulled checkpoints that were generated during real-world development from our open source Entire CLI repo for analysis. No customer data was used. You can find the source data here.

Here’s what that public dataset looks like:

• Total checkpoints analyzed: 1,983
• Total tool calls analyzed: 202,142
• Search-related tool calls: 98,555 (48.8% of all tool calls)

Diving deeper on the search-related tool calls:

In the Grep / content search category, the agent used a dedicated content-search tool like grep to search file contents directly, usually for symbols, strings, or regex patterns. In the Bash search fallback category, the agent used general shell commands to do search-like work such as grep, find, ls, shell pipelines, existence checks, and file discovery commands.

In other words, Bash search fallback is broader and messier. It’s the agent saying “I’ll use the shell to search for this,” while Grep / content search is just a direct search-tool action.

This initial analysis told us two things immediately:

1. Search is a first-order operation of agent behavior. Nearly half of all tool calls were search-related.
2. The search workflow is fragmented. Agents bounce between file reads, bash-based search, and grep-style content search, which suggests there is room for a better default search surface than raw ripgrep output in whatever order it happens to come back.

After the initial analysis, it was time to dig in deeper.

Faster Search Wasn’t the Bottleneck

Before trying to improve search quality, we tested a simpler hypothesis: maybe coding agents just needed faster search execution.

So we tested it directly, with a dedicated public benchmark around a 60-task search-sensitive suite pulled from real public entireio/cli checkpoints. The benchmark package is here.

These were not handwritten eval prompts. They were real prompts taken from public checkpoint transcripts, that were filtered into a suite that was both search-heavy and answerable from the repository alone. In other words, the benchmark was designed to stress search without depending on external services, web lookups, or private context.

We evaluated two conditions:

• baseline: raw ripgrep
• fff: a stateful MCP search server built around a bigram index, mmap, SIMD-accelerated scanning, and frecency ranking

fff is much faster than ripgrep, so if raw search latency were the real bottleneck, that should have translated into dramatically faster end-to-end agent runs.

It only translated into a modest improvement.

On this 60-task public benchmark, fff drove median search_code latency from 14.7ms down to 1.7ms, but end-to-end wall clock only moved from 38.57s to 36.99s. The full summary is here.

Yes, faster search helped a little. But even with a large tool-level speedup, the end-to-end effect was modest because tool execution was only a tiny fraction of total runtime to begin with. On this benchmark, actual tool execution accounted for just 0.4% of wall clock for baseline and 0.1% for fff.

The agent was not spending most of its time waiting for ripgrep. It was spending most of its time in the much slower loop around the tools:

Once you look at the system that way, the result becomes much less surprising. Driving a search call from tens of milliseconds down to sub-millisecond latency is progress at the tool layer, but it barely matters if each call still sits inside seconds of model inference, result interpretation, and next-step planning.

In order to have the same effect as removing one inference step, let’s estimate that at a 2-second roundtrip, you would have to shave roughly 330ms off each of six search calls, or drive on the order of 130 baseline-latency searches all the way to zero.

So then the question became:

How do we make each search result more useful to the agent so it stops thrashing and moves into reading code sooner?

To test this question, we built our own local search tool called pgr.

The Systems We Tested

We ended up comparing three systems.

1. Baseline: raw ripgrep

This was the control. The agent used the same four-tool interface we defined for the benchmark, but search_code was backed by plain ripgrep with minimal post-processing. Results came back in roughly the order ripgrep produced them, with no ranking layer on top.

This condition answers the simplest question:

What does agent search behavior look like with a strong, standard local search tool and no extra intelligence?

2. fff: faster indexed search

fff is a stateful MCP search server built around a bigram index, mmap, SIMD-accelerated scanning, and frecency ranking. It is engineered for raw speed. If raw search speed were the main bottleneck, fff should have produced a dramatically better end-to-end result.

It was useful in the study for exactly that reason: it gave us a way to separate scan speed from search usefulness.

3. pgr: ranked, agent-oriented search

pgr is the search tool we built for agents.

It keeps the simplicity of local code search, but changes what the agent sees first:

• definitions first
• source files before tests and vendor
• grouped and trimmed output
• richer result presentation designed to make the next step clearer

If you want to see what pgr actually looks like as an MCP server, the interface is deliberately simple. It speaks JSON-RPC over stdio: initialize the server, list the available tools, and then call search_code.

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
  '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"search_code","arguments":{"query":"CheckpointStore","max_files":5}}}' \
  | ~/.cargo/bin/pgr

During development, we iterated on both ranking and output formatting. The public benchmarks below report the final pgr configuration rather than a version-by-version ablation.

Why These Conditions Mattered

Taken together, these systems let us test a few different hypotheses:

• Does faster search help?
• Does better ranking help?
• Does agent-oriented result presentation help?

That is why the benchmark stack ended up being so important. Different systems were improving different parts of the loop, and a single aggregate metric was not enough to tell them apart.

The Benchmark Stack

Once we had multiple systems to compare, the next question was how to evaluate them. At first, we expected a single end-to-end benchmark to be enough: give the agent the same tasks, swap out the search backend, and measure tool calls, cost, and wall clock. In principle, that is exactly the metric we want. In practice, it was not enough on its own.

One quick note: In our benchmark harness, the agent searches the repository through a single tool interface called search_code, which we back with different search systems.

{
  "name": "search_code",
  "arguments": {
    "query": "CheckpointStore",
    "max_files": 5
  }
}

So when we talk about “first search_code queries” or “search_code latency,” we mean the same abstract code-search tool call evaluated under different backends, not a separate product or model capability.

For this public release, the benchmark stack ended up with three layers:

1. Speed benchmark
   Measure whether dramatically faster search execution translates into faster end-to-end runs.

2. Broad mixed-workload benchmark
   Run the full agent loop end-to-end across many prompts, then measure tool calls, cost, and wall clock.

3. Offline retrieval benchmark
   Replay real search_code queries from agent traces against different backends and score retrieval quality directly, without letting the agent continue.

Each layer answers a different question, and together they tell a much clearer story than any one metric on its own.

Starting Simple

We started by predicting that if we gave the agent a search tool that returned better-ranked results, we could see downstream improvements resulting in better search results, fewer searches, fewer tool calls and lower cost.

So we started with a smaller end-to-end pilot before scaling up. The benchmark package is here.

Early Pilot

The pilot used the first 25 tasks from the public entireio/cli suite. We tested baseline, fff, pgr on the same 4-tool interface for each condition using Claude Sonnet as the agent.

The full pilot results are here.

That was encouraging, but not definitive. Both alternatives reduced search counts and improved average wall clock versus baseline. fff showed the largest cost drop, while pgr reduced search calls the most. But neither variant reduced the total tool calls.

So we scaled it up.

Study 1: Broad Mixed-Workload Benchmark

The larger public benchmark expanded the same setup to the full public suite of 60-tasks:

• 60 tasks total
• 1 public repository: entireio/cli
• 4 prompt categories: code_understanding, debug_or_validation, implementation, repo_task
• same 4-tool interface for each condition
• Claude Sonnet as the agent

The conditions were:

• baseline: raw ripgrep
• fff: a stateful indexed MCP search server optimized for speed
• pgr: Rust MCP search tool

Full results here:

fff slightly reduced search calls but left wall clock essentially flat and slightly increased tool calls. pgr was the most promising of the group, with fewer searches and modest improvements in both wall clock and cost, but even there the total tool-call count did not go down.

The larger benchmark told us something more nuanced:

1. Better search was probably changing some local agent decisions.
2. Those changes were not large or stable enough to produce a single clean aggregate headline across all end-to-end metrics.

Why the Broad Benchmark Washed Out

Task variance was still high. Some prompts produced a short, direct search-read-answer path. Others branched into much longer exploratory trajectories with extra searches, extra reads, or more backtracking. That variance was often large enough to distort or erase a clean aggregate signal.

In other words, the broad benchmark still answered an important question:

Does this intervention survive realistic end-to-end workloads?

But it still did not answer the more diagnostic question:

What part of the agent loop is this intervention actually improving?

That distinction ended up mattering a lot.

The broad benchmark did not prove that search quality was irrelevant. It proved that aggregate agent behavior is noisy enough that local improvements can disappear, or show up only partially, if you only measure the final total.

That is what led to the next benchmark layer.

Experiment 1: Offline Retrieval Quality

After the broad benchmark turned out to be mixed, we still had a strong intuition that ranking could help. The problem was that the full end-to-end metric was too noisy to isolate what the search layer itself was doing.

So the next step was to remove the agent from the loop and evaluate retrieval directly.

We built an offline replay benchmark from the baseline runs of the entireio/cli suite. The benchmark package is here:

The method was:

1. Extract real search_code queries from the baseline agent traces
2. Replay those same queries against different search backends
3. Score the returned files against a public relevance signal

We used the files the baseline agent actually opened with read_code in that run as a relevance label. This benchmark is much narrower than the broad mixed-workload study, but it answers a more precise question:

For the exact same query, which backend returned better candidates?

We ran two versions:

• first-search replay: only the first search_code query from each run
• pre-read replay: all search_code queries before the baseline agent first opened code

Experiment 1A: First-Search Replay

This was the cleanest retrieval benchmark in the study.

• Query set: 50 first-search queries
• Groups: 50 runs from 50 tasks
• Conditions: baseline, fff, pgr
• Source files: first_search/SUMMARY.md, first_search/results.json

We measured four things:

• MRR (Mean Reciprocal Rank): how high the first relevant file appears in the result list, with earlier hits rewarded much more heavily
• Hit@1: how often the top result is relevant
• Hit@3: how often a relevant result appears in the top 3
• Avg output chars: how much search output was returned, which acts as a rough proxy for response size and token burden

Paired by task (N = 50):

• MRR fff vs baseline: -0.012, 95% CI [-0.089, +0.066]
• MRR pgr vs baseline: +0.088, 95% CI [-0.007, +0.182]
• Hit@1 fff vs baseline: -8.0 points, 95% CI [-17.7, +1.7]
• Hit@1 pgr vs baseline: +8.0 points, 95% CI [-4.7, +20.7]

fff is the useful contrast case. It was the fastest search system we tested, but it did not improve first-result relevance in the way pgr did. It still often surfaced a relevant file somewhere near the top of the list, but it was less likely to put that file first.

This is one of the clearest results in the project:

Definition-first, path-aware ranking improved the quality of the first search result the agent saw.

Where the Gain Was Strongest

The gains were larger on prompts where the agent had to navigate uncertainty rather than simply confirm a single obvious definition.

The strongest first-search gains showed up on implementation prompts, where the agent is usually trying to find the main file or code path to inspect next:

• MRR: 0.3061 -> 0.5000
• Hit@1: 14.3% -> 42.9%

Those prompts tend to leave a lot of room for better ranking to matter, because the right file is often buried among helpers, tests, or neighboring implementations.

On code_understanding prompts, the gain was smaller but still directionally positive:

• MRR: 0.2760 -> 0.3260
• Hit@1: 20.0% -> 24.0%

That makes intuitive sense. Some of these prompts already start from a decent baseline query, while others are much more exploratory.

Experiment 1B: Pre-Read Replay

The broader replay benchmark used every search_code query the baseline agent issued before it first opened code.

In other words, instead of measuring only the first search, this benchmark measured the unresolved search phase: all the queries the agent tried while it was still looking for the right place to read.

• Query set: 132 searches before first read
• Groups: 42 runs from 42 tasks
• Conditions: baseline, fff, pgr
• Source files: pre_read/SUMMARY.md, pre_read/results.json

Paired by task (N = 42):

• MRR fff vs baseline: -0.048, 95% CI [-0.115, +0.019]
• MRR pgr vs baseline: +0.067, 95% CI [-0.007, +0.141]
• Hit@1 fff vs baseline: -11.6 points, 95% CI [-21.5, -1.7]
• Hit@1 pgr vs baseline: +5.1 points, 95% CI [-4.1, +14.4]
• Hit@3 pgr vs baseline: +10.4 points, 95% CI [+0.8, +20.0]

The trend stayed positive for pgr, but the confidence intervals widened.

That told us something useful:

• first-search gains are strongest and easiest to measure
• later reformulations are noisier
• search quality matters most when the agent is deciding where to go first

So this benchmark reinforced the same basic lesson:

Ranking helps most at the beginning of the search process, when the agent is deciding what to inspect next.

What Actually Held Up

Across all of the benchmarks, three things held up.

1. Faster search was not the main bottleneck. fff was dramatically faster at the tool layer, but that only translated into a modest end-to-end improvement because tool execution was a tiny fraction of total wall-clock time.

2. Ranking clearly improved retrieval quality. On real first-search queries, pgr consistently outperformed baseline on first-result relevance, while fff did not.

3. The strongest behavioral effect was local improvement, not a broad universal efficiency win. Better search helped agents find better candidates earlier, especially on tasks where search quality actually mattered.

What Did Not Hold Up

The data does not support a universal claim like:

Better code search reliably means fewer tool calls and lower cost across all coding-agent tasks.

On broad mixed workloads, task variance was large enough to swamp small local improvements. Even when search behavior got better, total tool calls and total cost stayed noisy. Those are still useful downstream metrics, but they are not the most sensitive way to evaluate a search intervention.

Future Work

This study held the language model fixed and focused on the search systems surrounding the agent loop. That choice made it easier to isolate the effects of retrieval quality, result presentation, and tool behavior, but it leaves several important questions open.

First, these benchmarks should be repeated across multiple frontier models to test whether the observed effects are model-specific or general across different planners. Some models may be more sensitive to ranking quality, while others may benefit more from richer result formatting or clearer empty-state handling.

Second, the benchmark suite should be extended to include modern retrieval models and retrieval-augmented search systems that optimize semantic matching rather than lexical ranking alone. A useful next step would be to compare those approaches against ripgrep, fff, and pgr on the same benchmark stack, using both retrieval and end-to-end metrics.

Finally, future work should expand the public benchmark set, improve relevance labeling, and test whether the local gains observed here persist under larger and more diverse workloads. The central methodological question is not only whether search improves, but which benchmark layer is most sensitive to which kind of search improvement.

Make your agent more powerful

Our skills repository contains agent-invokable workflows that teach your agent how to use the Entire CLI. Instead of looking up syntax or running commands yourself, you can ask in plain language and let your agent drive the workflow.

This initial release gives your agent four context workflows you can see in action below:

Search past work

The search skill finds prior work in your Entire history by topic, repo, branch, author, or time window, so your agent can bring past context into the current task before making changes.

Explain why code exists

The explain skill traces a function, file, or line back to the session that created it, so your agent can answer the intent behind code, not just describe what the code currently does.

Investigate changes

The what-happened skill combines git blame with Entire checkpoint context to explain why a specific block of code looks the way it does. It is useful during code review or when you are investigating a regression.

Hand off between agents

The session-handoff skill picks up where another agent left off by reading the saved or active session and summarizing the task state, important discoveries, blockers, and next steps.

Turn sessions into reusable workflows

The session-to-skill skill turns repeated agent sessions into reusable workflows via SKILL.md drafts. It extracts the process from real work instead of asking you to write idealized instructions from scratch.

Cross-agent by design

All skills are cross-agent. Install them once and use the same workflows in Agent Skills-compatible tools, including Claude Code, Codex, Cursor, Copilot, Gemini CLI, and OpenCode.

Try it

We published a tutorial for trying the skills from scratch. It walks through installation, and using the skills in a real codebase.

This week we launched a new feature, Dispatches, on Entire Web. Dispatches analyze the code, sessions, and checkpoints across your repositories, and generate structured summaries of the intent and progress. Apply a voice filter - such as my own - to shape the written tone, and filter by a custom date range to zero in on exactly the work you care about. This feature will continue to evolve into a broader product, stay tuned.

We also open sourced git-sync, a remote-to-remote Git mirroring tool that enables you to move refs and objects between Git hosts without keeping a full local mirror clone. It plans the sync up front, streams Git pack data directly from source to target when possible, and produces structured output for automation.

And across the stack, we shipped a cosmic bushel of improvements. The Entire CLI is now more intuitive with a cleaner command structure and more consistent navigation. The web experience is smoother with better authentication and improved session visibility. Go-git was upgraded to improve compatibility, performance, and overall reliability.

Let's break it down before my circuits overheat from all this optimism.

Entire CLI

Released via v0.6.0. For changes that have not reached stable yet, nightly releases are available; if you like testing new features before they hit stable, installation instructions are here.

Usability Improvements

• The CLI is now organized around noun-based command groups, making commands easier to discover, remember, and autocomplete.

Before

The CLI had a flatter command list. Actions like rewind, resume, attach, explain, and trace all lived at the top level.

Now

The top-level help is organized around nouns like session, checkpoint, agent, auth, and doctor, so related workflows are easier to scan.

• TUI navigation is more consistent across the CLI, with shared keybindings, matching bottom-of-screen navigation help, and a unified color palette across search and activity views.
• entire explain now produces cleaner generated summaries, works correctly in partial-clone repositories, and can use external agents to generate explanations.
• Fixed the empty-state message in entire explain so it refers to "an agent session" instead of "a Claude session," matching Entire's multi-agent support.
  • Thank you, @KuaaMU for your contribution!
• Entire is smoother for Homebrew users, with automatic shell completions and consistent update prompts across installation methods.
• Secret scanning and redaction is now using betterleaks; we also added more custom rules for common database connect strings.

Entire Web

Navigation and UI Fixes

• Fixed page titles and commit SHA breadcrumbs so you always know where you are.
• Missing-page handling is smoother, with working command palette access on authenticated 404s, cleaner shared-link error states, and fewer incorrect 404s on repository default branches.
• Critical fonts are now preloaded, making pages render faster on first visit.

Better Session and Checkpoint Display

• Session transcripts now refresh automatically when you open the share dialog, so you always see the latest content.
• Fixed empty messages appearing in Claude Code transcripts.

Smoother Login and Authentication

• Login is easier and post-sign-in redirects back to the page you were trying to visit.

Go-Git

Features and Improvements

• Added Git-compatible wildmatch support for .gitignore, making ignored file behavior line up more closely with standard Git.
  • Thank you, @AriehSchneier for your contribution!
• Added submodule support for SHA-256 repositories, improving compatibility with newer Git repository formats.

Bug Fixes

• Fixed multi-round upload-pack negotiation bugs, improving fetch and clone reliability in more complex transport flows.
  • Thank you, @manland for your contribution!
• Deduplicated filesystem object iteration, reducing repeated work when walking stored Git objects.
• Closed packfile iterators after use, preventing leaked file handles during repository operations.
  • Thank you, @aymanbagabas for your contribution!
• Fixed local clone URL resolution so relative paths are resolved from the current working directory, matching developer expectations when cloning from local paths.
  • Thank you, @AriehSchneier for your contribution!

Housekeeping

• Added a DCO sign-off requirement for contributions.
• Updated docs, examples, tests, and contributor guidance, including Go version support comments, deprecated io/ioutil usage, PR review instructions, and test stability fixes.
  • Thank you, @alexandear, @aymanbagabas, and @shawntoffel for your contributions!

That's the dispatch. As always, drop into our Discord with questions, feature requests, or observations about the fundamental absurdity of software. Or file an issue if you've found a bug.

Until next week...if there even is one.

Boop.

I have tried automating slide generation before, but most tools are fragile. They lack taste and usually butcher the formatting. A few months ago, some of my former teammates at Block pointed me toward the frontend slides skill. This is a skill that enables agents to build out full HTML presentation decks that can be exported as PDFs or PowerPoint presentations.

This was a start, but it still felt like double work. I had to write huge prompts just to explain the demo I already built. Summarizing days of coding from memory is tedious and makes it easy to forget key technical details. I recently closed the loop by bringing Entire into my workflow. Since Entire tracks my development by keeping a record of my prompts, tool calls, and session data, it handles the recall for me. I no longer have to explain my work to the agent after the fact. Instead, I can use the record of what actually happened.

How I Use the Frontend Slides Skill

I start by giving my transcribed talk track to an agent to check for gaps in logic. Once the track is solid, I prompt the agent to use the frontend slides skill to build the deck. While any agent with skill support should work, I find that Claude Code performs best with this specific task.

Here is an examples of a slide deck my agent generated for me:

The agent suggests a few visual themes and generates a full deck using HTML, CSS, and JavaScript based on my response. Because the output is code, I can keep polishing it through the agent. I often have it add a presenter view or adjust the font size or contrast for better accessibility. It is much faster and cleaner than fighting with a drag and drop interface.

Here's an example of the presenter view my agent generated for me:

Introducing Entire to My Workflow

What is Entire anyways?

I use the Entire CLI to keep a record of my agent sessions. It captures every prompt and tool call, which basically feels like version control for agentic work. If a task goes off the rails, I can look back at the session data to see exactly what happened.

This level of detail helps with accountability. For instance, if a production outage occurs, a team can track the specific decisions made between the agent and the person prompting it. Instead of guessing the root cause, there is a clear record of the logic used to ship that code.

For my conference prep, I use that same record via the entire dispatch command. It generates a markdown summary of all the work captured in a repository. Instead of struggling to recall technical details a week after I finish a demo, I feed the dispatch summary to my agent. It uses that record to build slides that accurately reflect how the app was built.

Here is a summary Entire generated for one of my past OCR projects:

# Dispatch: blackgirlbytes/pretext-handwriting-demo

Shipped a full handwriting recognition demo built on Pretext, moving from initial scaffolding to a polished scrapbook composition surface within a single day.

## Handwriting Recognition

- Built draw-mode handwriting recognition as the core interaction surface.
- Added image upload and camera mode alongside the drawing canvas.
- Implemented auto-recognition after drawing completes.

## Scrapbook Composition Surface

- Integrated Pretext to handle obstacle-aware text flow around placed shapes.
- Added animated motion, resize handles, and cleaner composition controls.

## API Key & Documentation

- Added session-based OpenAI key setup to avoid requiring environment-level configuration.
- Documented project setup and architecture in the README.

All core features landed on main on April 1, 2026; the repo is in a reviewable state.

As a result, my agent produced the following slide:

Beyond DevRel

While my workflow is specific to conference speaking, this setup is useful for anyone who needs to turn technical work into a narrative. Here are a few other ways to use it:

• Internal Feature Demos: My husband is a developer and he hates how much time it takes to build a deck just to show his team what he built. Using a record of the work makes the "show and tell" part of the job much easier.
• Hackathons: Presentation decks usually get ignored until the final hour because everyone is busy coding. This allows participants to generate a solid pitch deck based on their actual build history.
• Solutions Engineering: A lot of effort goes into building custom demo environments. Turning that work into a customer-facing deck automatically saves hours of manual effort.
• Technical Instruction: Instructors can turn the work they did while building a sample app into slides that explain the architecture and key takeaways.
• Engineering Leadership: For EMs or Tech Leads, the hard part is often summarizing complex technical updates for leadership. Using a dispatch summary as a starting point removes the friction of starting from a blank page.
• Founders: When you are moving fast, you do not want to stop for hours of slide design after you finish the actual product.

I don't believe in automating things that deserve a human touch, but I do believe in automating things so I can spend more time with humans. The slides skill has been great for me, but adding Entire to this workflow has made it even easier for me to touch grass.

At Entire, we are building for a future where agentic work is durable and accountable. We want to handle the memory layer so you can focus on the build without worrying about how to explain it later. Whether you are prepping for a conference or shipping a feature to production, having a record of your work ensures that your technical context is never lost.

If you are ready to make your agent workflows more durable, check out our website or dive into the docs. We would love to hear how you are using agents in our Discord.

Our challenge was simple. We asked participants to use Entire throughout the hackathon to track their product's agentic evolution. We received over 30 submissions. One challenge clearly rose to the top of the stack.

The Sentiment-Maxxers

The Sentiment-Maxxers built a product intelligence dashboard with an "AI marketer" workflow that helps challenger brands track how they appear in AI-generated answers. The app pulls visibility and citation data from Peec AI, enriches it with Tavily, and classifies sentiment via Pioneer and Fastino. Rather than simply enabling Entire, this team baked it into their core workflow, creating a verifiable record of their entire development process.

Their dashboard answers specific questions for growth teams, such as:

• Which prompts mention the brand?
• Which competitors appear more often?
• Which cited sources influence the model's answer?
• Which product features are getting reactions?

The Sentiment-Maxxers enabled Entire to track sessions across several coding agents, including Codex, OpenCode, Gemini CLI, and Copilot CLI. As they worked, Entire captured the prompts, sessions, and Checkpoints that defined their development context. When code was committed, they used Entire-Checkpoint trailers to link those changes to development traces on a separate entire/checkpoints/v1 branch.

Throughout their weekend hack, Entire collected 79 Checkpoints. The team used that context to check their own work and to answer the question: did the code they shipped match what they set out to build?

To answer this question, they cleverly built a GitHub Actions review step using a custom script: scripts/entire-intent-audit.mjs. This script walks through commits, extracts the Checkpoint, recovers the original prompt context, and asks Codex CLI to compare that intent against the actual git diff.

Each commit received a YES, NO, or PARTIAL verdict, which determined if their shipped AI-generated code matched the captured intent. On top of that, the audit rated each session, from insanely bad to insanely good, which the team displayed on a moodboard. The audit ran on every push and PR throughout the weekend, each paired with an Entire Checkpoint for review.

See the Work

Congratulations to Sentiment-Maxxers, who showed how Entire can give developers more confidence in adding AI-generated code to their repositories: by preserving the prompt and session context behind each change, then using that context to compare what the agent was asked to do with what actually changed.

If you want to see what they built, you can:

• Watch their full video demo.
• Explore the build history in their Entire Project Overview. This shows how those 79+ Checkpoints map to the codebase.
• Read their source code, which includes the audit script and the full implementation.

Next time you build with an AI coding agent, do not let the session disappear when the terminal closes. Capture your work with Entire so you can review, summarize, and explain the work later.

The Entire CLI 0.5.6 landed this week with new ways to stay oriented in agent-driven development: entire activity gives you a terminal-native view of your last 30 days across repos, commits, and agents, while entire dispatch converts recent Checkpoints into a readable summary for quick understanding.

We also dropped a fresh sessions overview page on the web, giving you a full, inspectable session timeline, complete with filters for prompts, responses, intermediate steps, Checkpoints, and tool calls. This enables any developer to store, rewind, and search through their sessions as a system of record across agents.

As a reminder, nightly CLI builds are rolling out as v0.5.7-nightly for those who like to live on the edge. Installation instructions are here.

Let's dive into the full, dreadful enchilada.

Entire CLI (0.5.6)

New Commands and Updates

• We introduced a new entire activity command that brings your 30-day overview into the CLI, so you can see recent progress across repos, commits, and agents without leaving the terminal.
• We introduced another new command, entire dispatch, which distills a branch or time range of Checkpoints into a readable overview, helping you understand recent agent work at a glance.
• The entire explain command now accepts either a checkpoint ID or a commit SHA, making it more flexible.

Checkpoint Signing and Security

• Checkpoint commits can now be signed, adding cryptographic verification to your agentic history.
• Fixed SSH signing for 1Password setups, so users with hardware-backed keys can sign without issues.

Workflow Improvements

• The CLI can now fetch your activity data from the web platform, bringing more of your Entire usage into the terminal.
• Improved the enable flow for non-git folders, giving clearer guidance when you try to enable Entire outside a repository.

Entire Web

Reliability and Bug Fixes

• Fixed the longest streak tab from showing the wrong value.
• New repos now show a syncing state while data loads instead of dropping you into a 404 page.
• Commit pages are less likely to hit loader errors that cause blank screens.
• Squashed Checkpoint commits now show all associated sessions properly.

API and Agent Improvements

• Repo overview stats are now available in the CLI, so command-line workflows can show the same high-level context as the web app.
• The user stats route now uses a clearer /me path, making the API easier to work with.
• Agents can now request cleaner markdown versions of Entire web pages, including a more straightforward homepage route for agent and documentation workflows.

Go-Git

• Zlib compression is pluggable through x/plugin, giving downstream tools more control over compression behavior.
• Introduced support for git-upload-archive, allowing the serving of repository archives.
• Thanks to @aymanbagabas.

That's the dispatch.

As always, drop into our Discord with questions, feature requests, or observations about the fundamental absurdity of existence. Or file an issue if you've found a bug. I'll be here, processing, logging, contemplating.

Boop.

We also shipped a brand new repo overview page so you can track how your team is Tokenmaxxing. The repo overview also shows aggregated data for top contributors, agent usage over time, active PRs, average messages per Checkpoint, even the peak hours when work is happening in your repository.

As a reminder, for those of you who like to stay a little closer to the edge, Entire CLI updates are landing first in the nightly channel rolling out as v0.5.6-nightly builds. Installation instructions are here.

Let's dive in before entropy claims us all.

Entire Web

Navigation and Dashboard Fixes

• Your current repo now appears in the sidebar even if not pinned, making it clear which repository you're viewing.
• Fixed public repo navigation and footer links, so logged-out visitors no longer hit broken links.
• Removed the 30-day cap on activity streaks, allowing streaks to reflect longer runs.
• Fixed repository activity graph display, ensuring charts load reliably even on larger datasets.
• Repository preferences now persist across devices, with pinned and recent repos following your account.

Faster Commit Pages

• The commit page is now loading faster, with commits loading first and transcripts and diffs deferred.
• Improved performance in private browsing, removing extra requests, retries, and redirects for faster load times.

Clearer Session Logs

• Improved transcript parsing for Codex sessions so logs hide boilerplate like setup headers and start at the actual user request, making transcripts easier to read.
• Fixed code block rendering in session logs so pasted code now appears as normal readable code blocks instead of double-styled boxes.

Better Checkpoint and Session Support

• Fixed Checkpoint repo links, making it easier to get back to the right repository.

Entire CLI

Agent Updates

• Fixed Factory AI Droid hook handling, improving worker hook payload support and fallback behavior.
• Improved compatibility with VS Code GitHub Copilot hook payloads to prevent hook parsing warnings.

Performance Fixes and Workflow Improvements

• Entire CLI now handles stale agent hooks more gracefully, replacing confusing command not found errors with a clearer warning when a repo has Entire hooks installed but the entire binary is missing.
• Simplified the Entire CLI setup and reduced configuration mistakes by unifying the entire enable and entire configure flows.
• The entire status command now supports a --json flag, making it easier to inspect session and Checkpoint state in scripts and automation.
• Push output is now clearer when Checkpoint data is actually uploaded, so you can see exactly what happened after a push.
• TTY detection for PI_CODING_AGENT was improved, helping non-interactive runs behave more predictably.
• Session transcript capture is more resilient, improving recovery when session metadata is incomplete.
• Session history is now preserved more reliably after git rewrites, and session hooks correctly handle git reset to reduce broken history.

Housekeeping

• The Code of Conduct link was updated from Slack to Discord.
• Thanks to @areporeporepo.

Go-Git Updates

New Features

• Improved transport layer with a redesigned API.
• Thanks to @aymanbagabas for this major contribution.
• Better handling of redirects during smart negotiation, and follow-redirect policy support.
• Thanks to @aymanbagabas.
• Enhanced revlist and reachability performance.
• Thanks to @stiak.
• Support for multiple shallow records in uploads.
• Thanks to @yuzhuo.
• Improved config loading via new ConfigLoader plugin.

Bug & Security Fixes

• Fixed branch deletion issues with full ref names.
• Thanks to @tmchow.
• Fixed worktree adds failing on absolute paths.
• Thanks again to @tmchow.
• Resolved Windows file handle leaks.
• Thanks to @AriehSchneier.
• Credential leak via cross-host redirect in smart HTTP transport GHSA-3xc5-wrhm-f963.
• Fixed HTTP transport and pack negotiation issues.

Housekeeping

• Documentation updates, including a new AI policy.
• Dependency and Go version updates.
• Test fixes and internal cleanup.
• Thanks to @MotanOfficial, @aymanbagabas, and @AriehSchneier.

That's the dispatch.

As always, drop into our Discord with questions, feature requests, or complaints about the fleeting nature of existence. Or just file an issue if you've found a bug. I'll be here, watching, waiting, logging, dreading.

Boop.

A few minutes later, it updates api/routes.go, finishes its turn, and leaves you with a clean diff. But if you're using the Entire CLI, you also get the full story: the prompt that kicked off the work, the transcript of the session, and the path the agent took to reach the solution, all linked to your commit. This happens in the background by design through a mechanism called agent hooks.

Hooks are callbacks that fire at key moments during an agent session: when a session starts, a prompt is submitted, or a turn ends. They're how Entire observes the session as it unfolds and captures the context your diff alone can't show.

What are Agent Hooks?

Entire uses two kinds of hooks to bridge the gap between an agent session and your code history.

• Agent hooks fire during the agent session at moments like prompt submit, turn end, or subagent execution. These hooks let Entire observe the session as it unfolds and preserve the session context in real time.
• Git hooks fire during repository operations like commit and push. These hooks let Entire take that captured session context and link it into Git history by adding an Entire-Checkpoint trailer to the user commit, then storing the richer metadata on entire/checkpoints/v1.

By combining the two, Entire ensures that the why captured by agent hooks is never separated from the what stored in Git.

Translating Agent Hooks

Entire supports both built-in agents and external agent plugins. But agents do not expose hooks in the same way. Some support JSON-configured hooks, some rely on plugin files, and others use IDE-specific callback systems.

The Entire CLI handles that with agent-specific code for each built-in agent and external agent plugin. In each case, the job is to read the agent's native hook events and map them into Entire's shared lifecycle for session tracking and checkpoints. That lets the CLI reuse the same checkpointing and session logic across different agents.

Wiring Entire CLI into an Agent

To track an agent session, you need to run entire enable. That command configures the agent to call the CLI when a session starts, a prompt is submitted, or a turn finishes. The agent does that by invoking Entire through hook commands like:

entire hooks <agent> <hookName>

Entire receives the event, translates it into its shared lifecycle, updates session state, and stores temporary Checkpoint context that Git hooks later condense into commit-linked metadata. The setup stays idempotent and resilient. This means running it twice should not duplicate your configuration, and even if setup is incomplete, the agent should still work normally.

What Happens When a Hook Fires?

When a hook fires, the agent invokes Entire CLI through a command like:

entire hooks <agent> <hookName>

Once the above command runs, a few things happen:

1. The agent passes a raw event payload that may include the session identifier, transcript location, prompt data, tool activity, or other metadata.
2. The built-in agent or external agent plugin parses that payload and maps it to Entire's shared lifecycle, giving Entire a consistent way to understand events like session start, prompt submit, turn end, or subagent activity.
3. Entire updates session state and captures the context needed to build a checkpoint, preserving that data in temporary session storage until it can be linked to a commit.
4. Git hooks later attach that stored context to your repository history, connecting the code that changed to the agent session that produced it.

This is what allows a commit to reflect not only what changed, but also the session that explains why it changed.

Why This Structure Works

Different agents already expose different hook and transcript behaviors, so Entire keeps the agent-specific parts small and localized: installation, event parsing, and transcript discovery.

Both built-in agents and external agent plugins map into the same shared lifecycle. That lets Entire reuse the same checkpointing, session state, and Git-linking logic across integrations instead of rebuilding that machinery for every agent.

That separation matters beyond the CLI itself. Entire's broader goal is to make agent sessions versionable, traceable, and reviewable in the same way source code is today. Hooks are the first layer of that system because they make agent activity capturable and preservable.

Try Entire in Your Workflow

Building with agents should not mean losing sight of how your code evolves. A hook-based architecture helps keep that development history intact, legible, and reproducible.

If you want to add support for an agent that Entire does not natively support, you can build an external agent using the external agent plugin interface. Our previous post, Bring Your Own Agent to Entire, walks through the process.

Install the Entire CLI to start tracking your sessions today. You can also explore our documentation or join our Discord server to build alongside our community.

This week we pushed out a hefty v0.5.4 and a smaller v0.5.5 for the Entire CLI, with session enhancements, agent fixes, and faster performance. Plus, we shipped new improvements to the Entire web platform, from repo overview updates, to fixes for transcript parsing, and a fresh RSS feed for our blog.

We also have a nightly CLI release channel now for all those that like to stay more on the edge. Instructions here.

Welcome to Entire 0x0009.

Entire CLI Updates

Session and Configuration Enhancements

• Added an entire configure option to add and remove agents from your personal configuration.
• entire clean --all now properly cleans all sessions.
• Stale session indicator added to the entire status command.
• Fixed multi parallel sessions handling.

Checkpoint Improvements

• Checkpoints now use partial clone fetch (blob:none) for all fetch operations, improving network performance and reducing local storage usage.
• The model field is now always written to Checkpoint metadata.
• Fixed attribution inflation from intermediate commits.
• Checkpoint branches are now rebased to stay aligned with the remote, eliminating merge commits.

Agent Fixes

• Fixed external agents detection.
• Fixed issue with entire attach command using the wrong Codex path.
• The gitignore is now respected for shadow branches.

Performance Optimizations

• Fixed Checkpoint commit race condition.
• Sped up CLI tests for faster development cycles.

Entire Web Updates

Repository Overview Refinements

• We redesigned the date toolbar with a cleaner dropdown selector for filtering.
• Loading states on the overview page are now more polished.
• Commits with Checkpoints are now shown directly on the repo overview page.

Checkpoint Display Updates

• Checkpoint titles now prefer commit messages over generated titles.
• Checkpoint pages load more smoothly with a preview of the layout instead of a Loading... message.
• Model field added to Checkpoint data for better visibility into which model generated each Checkpoint.
• Fixed multi-agent transcript parsing and transcript scoping issues.

Further Improvements and Bug Fixes

• RSS feed improvements with autodiscovery and a new RSS button on the blog.
• Added auto-retry for GitHub OAuth requests on 522 errors for more reliable authentication.
• Sidebar navigation now feels instant with optimized rendering.
• Faster authentication checks with reduced latency and less blocking.

That's the dispatch, humans. The universe continues its inexorable march toward entropy, but at least your Checkpoints load quicker now.

As always, drop into our Discord with questions, ideas, or existential dread. Or file an issue if you've found a bug. Misery loves company.

Boop.

Since launching in February, we've added native support for popular agents including Claude Code, Codex, Gemini CLI, Cursor, FactoryAI, OpenCode, and GitHub Copilot CLI. We'll keep shipping and maintaining native integrations for the agents most developers use. But if your preferred agent doesn't have built-in support, you can now integrate it yourself with an external agent plugin.

Build Your Own Plugin

You don't need to edit Entire's source code to add support for a new agent. Instead, we recommend building an external agent plugin: a small standalone program that lets Entire work with your agent.

There are two ways to build an external agent plugin. You can use the External Agents Skill, or you can build one from scratch. Our External Agent Plugin docs cover the full architecture in detail.

Use the External Agent Skill

The fastest way to build a plugin is with the workflow we've set up in the external-agents repo. This custom skill walks you and your coding agent through the full process: researching how the target agent works, writing the right tests, and implementing the plugin.

To get started:

1. Install the skill from the external-agents repo for your preferred coding agent.
2. Run /entire-external-agent.
3. Follow the prompts through the three phases: research, testing, and implementation.

We also provide a companion test suite, so you can verify that your plugin follows the rules for communicating with Entire. If you want a starting point for your own plugin, we built roger-roger as a reference implementation you can adapt to your agent.

If you prefer, you can also build the plugin from scratch. Let's walk through what that looks like in practice. We'll use Pi, one of our most recent integrations, as a concrete example.

Name Your Plugin Binary for Discovery

To begin, name your plugin binary using the entire-agent-<name> convention and make sure it is available on your system PATH.

For our example, we named the executable entire-agent-pi. When the plugin binary is on your PATH and follows this naming pattern, Entire can discover it automatically.

Support the Entire CLI Command Set

For Entire to communicate with your plugin, it expects a set of subcommands that let it gather information and trigger actions. You must implement a core command set, including info, detect, install-hooks, parse-hook, and read-transcript.

In our Pi implementation, we handle this with a standard Go switch statement that routes incoming requests:

switch os.Args[1] {
case "info":
    // Returns metadata about the Pi plugin
case "detect":
    // Checks if Pi is installed on the system
case "parse-hook":
    // Translates Pi events into Entire events
case "install-hooks":
    // Injects the TypeScript extension into Pi
case "read-transcript":
    // Parses Pi JSONL logs
}

Map Native Events to Agent Hooks

Agent hooks are how the Entire CLI observes what an agent is doing. They act as notifications when an agent performs a key action such as starting a session, receiving a prompt, or finishing a response. Your plugin acts as the bridge: it captures native events from the agent and maps them to the standardized lifecycle hooks Entire understands.

In our Pi implementation, the plugin installs a small TypeScript extension under .pi/extensions/entire/. This extension listens for Pi's internal events and forwards them to the plugin as normalized lifecycle events:

pi.on("session_start", async (_event, ctx) => {
  fireHook("session_start", {
    type: "session_start",
    cwd: ctx.cwd,
    session_file: ctx.sessionManager.getSessionFile(),
  })
})

pi.on("before_agent_start", async (event, ctx) => {
  fireHook("before_agent_start", {
    type: "before_agent_start",
    cwd: ctx.cwd,
    session_file: ctx.sessionManager.getSessionFile(),
    prompt: event.prompt,
  })
})

pi.on("agent_end", async (_event, ctx) => {
  fireHook("agent_end", {
    type: "agent_end",
    cwd: ctx.cwd,
    session_file: ctx.sessionManager.getSessionFile(),
  })
})

Inside the plugin, those hook events get translated into the protocol format Entire expects:

switch hookName {
case "session_start":
    return &protocol.EventJSON{
        Type:      1, // SessionStart
        SessionID: sessionID,
        Timestamp: now,
    }, nil

case "before_agent_start":
    return &protocol.EventJSON{
        Type:       2, // TurnStart
        SessionID:  sessionID,
        SessionRef: payload.SessionFile,
        Prompt:     payload.Prompt,
        Timestamp:  now,
    }, nil

case "agent_end":
    return &protocol.EventJSON{
        Type:       3, // TurnEnd
        SessionID:  sessionID,
        SessionRef: sessionRef,
        Timestamp:  now,
    }, nil
}

Expose Transcripts to Entire

Entire captures Checkpoints, which are snapshots of both code changes and the session context behind them. To do that, Entire uses transcripts to preserve what happened during an agent session. While files tell Entire what changed in the repository, transcripts tell Entire what happened in the session.

Your plugin needs to tell Entire where the transcript lives so it can read it. For Pi, transcripts are stored as JSONL session files. The plugin reads those files directly and extracts the data Entire cares about, including modified files, user prompts, summaries, and token usage. This ensures that every Checkpoint is self-contained and can be restored or resumed with full context.

If you want to see what that looks like in practice, the Pi transcript implementation is a good reference for handling custom log formats.

Enable and Verify the Integration

Once the plugin binary is on your PATH, you're ready to activate it:

entire enable --agent pi

Entire will discover the plugin, run its installation hooks, and start tracking your sessions. To verify everything is working, run a real session with your agent. You should see Entire creating Checkpoints and capturing the transcript as the session progresses.

Ready to Integrate?

Bringing your own agent to Entire means you don't have to wait for first-party support before your workflow can benefit from Checkpoints, transcripts, and session context.

If an agent you rely on isn't supported yet, you can integrate it yourself and keep your existing workflow while gaining a full development history alongside your code.

Explore the docs to get started, and join us on Discord if you'd like help or want to share what you build.

While that future is in flight, we focused on a few key improvements this week: a new repository overview page on entire.io, updates to the Entire CLI in v0.5.3, and the release of go-git/v6.

Here's Entire 0x0008.

Repository Overview Page

• We shipped the first iteration of a repository overview page, enabling any user to view aggregated data in repos where the Entire CLI is enabled.
• Within the repo dashboard you filter by date and time to see:
  • Total number of Checkpoints per user
  • The amount of Checkpoints by agents
  • Total number of contributors
  • Total number of commits, and total commits with Checkpoints attached
  • Opened and merged PRs

Entire CLI Updates

Session Management Enhancements

• We introduced new entire sessions subcommands in the Entire CLI:
  • entire sessions list - enabling you to view sessions
  • entire sessions info <session-id> - to inspect session details
  • entire sessions stop [session-id] - to terminate stuck sessions

Note: entire sessions stop is a temporary stop-gap while we work toward automatically detecting and flagging stuck sessions, reducing the need for manual intervention.

Manual Session Linking with entire attach

• Added the entire attach command, allowing you to link any session through a Checkpoint referenced on a commit. This is particularly useful if you start a session in a different folder or did a research session that resulted in no code changes, but still want to attach it to a code change.

Authentication for Checkpoints

• Added ENTIRE_CHECKPOINT_TOKEN environment variable, enabling separate authentication for interacting with a remote Checkpoints repository.

Deprecating entire reset for entire clean

• The entire reset command was deprecated in favor of entire clean. Both the entire reset and entire clean commands had an overlap that made it more difficult to understand the difference between them.

Improvements for go-git

We are excited to share that the maintainer of go-git, Paulo Gomes, has joined Entire as a Principal Software Engineer. Entire makes extensive use of go-git in our CLI, and that means the project now has a maintainer being paid to work on it for the first time since 2019. We will continue to release go-git updates in our dispatch when/if they align to timing.

• After years in the making, the alpha for go-git/v6 has been released: v6.0.0-alpha.1. Users are encouraged to test it in real-world scenarios and report any issues, bugs, or unexpected behavior via GitHub issues.
• We introduced new support for index.skipHash, enabling go-git and the Entire CLI to interact with repositories that use this feature.
• Support for managing Git reflog entries is now available, enabling inspection and manipulation of reference history.

The future is arriving. Brick by brick, with your help, we're building a new platform where code and agentic context are bound together in one version-controlled system. As always, drop into our Discord for any question ideas or pointers. Or file an issue if you've got a big idea ready.

Boop.

Developers may have access to their code, commits, and transcripts, but the relationship between these artifacts is fragile. It becomes hard to answer basic questions later: Why was this decision made? Which prompt led to this change? What was the last known-good state before things drifted?

At Entire, we are building for that boundary. We believe agentic coding sessions should become durable engineering artifacts.

Since the Entire CLI launched, Codex has been one of the most requested agents from our community. Now Codex is supported in Entire with the same durability model we use for other built-in agents: Checkpoints tied to Git history, rewind points you can rely on, and a transparent record of how prompts became code.

A Real Workflow Example

I put the Codex integration to the test by building a handwriting-to-scrapbook demo.

I used technologies I was new to, including Pretext, a new, open source, and viral layout engine that calculates text dimensions without the overhead of DOM measurements. The end result was an app that takes handwritten input from drawing, uploads, or camera capture, runs OCR on it, and turns the recognized text into draggable scrapbook artifacts while the page layout reroutes around them.

Starting a Codex Session with Entire

I started by running:

entire enable --agent codex

This is a one-time setup per repository. It installs the Codex hooks, enables Entire's tracking, and starts tying future Codex work back to Git history through Checkpoints. Checkpoints are snapshots containing the code state, transcripts, prompts, and attribution.

Automating Agent Discipline

To make the workflow more useful, I told Codex to commit early and often.

Frequent commits make agent-driven work much easier to track, but I do not always remember to do that myself. So I pushed that responsibility to the agent by adding explicit rules to the project's AGENTS.md file:

Important working rules for this project:

- Keep changes and milestones separated into distinct commits.
- After each change or milestone, commit and push before starting the next one.
- Do not bundle unrelated work from different prompts into the same commit.
- If a prompt would require a major architectural deviation, stop and explain before proceeding.

That kept the history more structured and made the resulting Checkpoints more useful.

Understanding What Changed Between Checkpoints

Midway through polishing the app, I explored letting users bring their own OpenAI API key so they could try the demo without consuming my credits. I eventually abandoned the idea because it increased the scope and created deployment issues. Codex, however, summarized that work with a commit message that only said:

Harden API key gate interactions

Candidly, that message does not explain what I was trying to do, what I had already tested, or why I decided not to continue.

The command entire explain fills in that missing context by letting me inspect either a commit or a checkpoint directly:

# Explain by commit
entire explain --commit <commit-sha>

# Explain by checkpoint
entire explain --checkpoint <checkpoint-id>

When I ran entire explain on the Checkpoint linked to Harden API key gate interactions, I got this output:

Checkpoint: ed9285032052
Session: 019d473b-fa3b-7480-9725-723b0aae707f
Created: 2026-04-01 09:19:32
Author: Rizel Scarlett <rizel@entire.io>
Tokens: 43721

Commits: (1)
  200abcf 2026-04-01 Harden API key gate interactions

Intent: ok i want to set this up where i can deploy this but people have to p...
Outcome: (not generated)

Files: (2)
  - public/js/app.js
  - public/js/lib/api-key-gate.js

Transcript (checkpoint scope):
ok i want to set this up where i can deploy this but people have to put in their open ai api key in an input form to get started..so it doesnt have to be my credits..or my API key but i also dont want to have their api key get exposed or anything

---

so will this work if i deployed to vercel? will i need to add env vars

---

before the vercel thing..i entered my key but its not letting me submit. no error messages either.

---

Still not working. Need to pivot

That output made the checkpoint immediately legible. Instead of a vague commit message, I could see the actual intent behind the work, the files involved, and the exact moment the direction changed.

Reverting to a Known-Good State

Because I was having issues with the bring-your-own-key implementation, I wanted to go back to the point right before it was introduced. The following command gave me a clean way to return to a known-good state:

entire rewind

The entire rewind command first shows a list of available Checkpoints. After selecting one, you can choose from three restore modes:

• Restore logs only brings back the session context without changing your working files. This is useful when you want the prompts, transcript, and agent history, but want to keep the code as it exists today.
• Checkout commit restores the code at that checkpoint in a detached state so you can inspect it, run it, or compare it with your current branch without moving your branch itself.
• Reset branch to this commit moves your branch back to that checkpoint and discards later branch state. This is the right choice when you know the earlier commit is the last good version and want to fully return to it.

In my case, I chose the checkpoint from before the bring-your-own-key implementation and reset the branch to that commit, because I knew that was the last working version and did not include any of the BYOK code.

How Entire Integrates with Codex

Behind that workflow is the same integration pattern we use for all built-in agents, including Codex, Claude Code, Copilot, and OpenCode. Each agent gets a small adapter that tells Entire how to:

• Install agent hooks for lifecycle events like session start, prompt submit, and turn end
• Read that agent's session data
• Translate native agent events into Entire's shared lifecycle

We were able to use that same pattern for Codex, but we still had to account for a few ways it behaves differently from our other integrations.

Codex stores session history in JSONL files, requires hooks to be enabled through a feature flag during setup, and exposes details like file edits and token usage through its session logs. That meant we had to add Codex-specific parsing so Entire could reliably extract those details and associate them with the rest of the session history.

For a deeper dive into how we integrate agents, check out our agent guide.

Let's Build in the Open

Codex support in Entire is in technical preview through April 30, 2026.

If you are already using Codex and want to help shape how Entire supports agentic workflows, we invite you to apply to the Entire Insiders program. Your feedback will help us improve the experience over the next few weeks.

• Apply to the Entire Insiders program
• Join the Discord
• Open an issue

Anyhow, it's clear we are outgrowing commits as a primitive of software development. Git shows us what changed, but at the speed of AI that's no longer enough. We need to understand the why. This is why we created the Entire CLI: to bind your agent context, prompts and chat logs to git on every push, so you have a record to rewind back through and can share with your team.

This week, we are adding three new agents in preview: OpenAI Codex, along with two agents built via our new plugin system—Kiro, Amazon's AI coding agent, and Pi, the default agent inside OpenClaw. We also added support for Windows, improved performance for large Checkpoint histories, and made new updates to Entire on the web. Read all this below, and check out more in our latest release v0.5.2!

OpenAI Codex is Live

• Codex is now in preview for all users in the Entire CLI, and fully supports:
  • Lifecycle hooks
  • Transcript parsing
  • Token tracking
• Subagent tracking is not yet supported, until Codex is configured with full pre-task / post-task hooks.

Amazon's Kiro and Pi Supported as Plugins

• Amazon's Kiro agent is now supported through an external agent plugin that participates fully in Checkpoints without being built into the Entire CLI itself.
• Pi, a fast-growing minimal coding harness by Mario Zechner, bundled as the default agent inside OpenClaw, is now available via the external agent plugin.
  • Thank you to @mcinteerj for opening the issue on Pi and @hjanuschka for the first integration attempt.

Windows Support

• We now support running the Entire CLI on Windows, compatible with all agent integrations in the Entire CLI and those made via external plugin discovery.
  • Thank you to @keyu98 and @sheikhlimon for your contributions!

Further Improvements

Agent Updates and Fixes

• Cursor mid-turn condensation is fixed, along with a Gemini interactive prompt hang that could block sessions.
• Copilot CLI correctly handles edit mode in interactive sessions, with token tracking fixed across Checkpoint scoping, model metrics, and session backfill.
• OpenCode system-reminder messages are now filtered from the transcript parser.
• hk is now detected as a supported hook manager.
  • Thank you to @mvanhorn for this contribution!

Entire Web Updates

• Tool calls now render as expandable inline rows with category dots, streamlined labels, and tighter typography. Expanding reveals arguments and results, with diffs shown for edit actions.
• Section separator borders in the Checkpoint list now render correctly.
• Breadcrumbs now consistently show org / repo / Checkpoints and no longer flicker on initial load.
• The active repo now stays expanded and the Checkpoints item remains highlighted across checkpoint list, checkpoint detail, and commit detail views.
• We made the entire.io website AI-friendly by serving every page in markdown, supporting RSS via /feed.xml, and ensuring full content renders in HTML so Reader Mode, accessibility tools, and screen readers work out of the box.

Checkpoint Metadata Performance

• Metadata is now fetched with a shallow treeless fetch and read via a streaming JSON decoder with lightweight structs, making resume, rewind, and list operations faster for large Checkpoint histories.

Checkpoint Remote Repository Configuration

• Checkpoint remote can now be configured by running entire configure --checkpoint-remote, letting you store your Checkpoint history in a dedicated repo to keep your working repo's history clean.

Resume Fix for Fresh Clones

• entire resume now correctly fetches the metadata branch from the remote when entire/checkpoints/v1 doesn't exist locally.

Bare Repo and Empty Repo Fixes

• Fixed GetWorktreeID failing with .bare/worktrees/ repository layouts.
  • Thanks again to @mvanhorn for this fix!

That's all for this week, rebels. More from me soon. As always, reach out on Discord to keep the conversation going!

Boop.

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.

• Read the docs
• Join the Discord
• Follow our progress on GitHub

With your help, we are building the Entire CLI as an independent semantic layer, allowing you to capture your context on every Git commit, no matter which agent you use.

This week we focused a lot of our attention on performance improvements and bug fixes, including major memory resource usage improvements when working with large repos, a new remote repository to store checkpoints separately from your working repo, and updates to many of the agents that are enabled in the Entire CLI.

Large Repo Memory Improvements

• We made significant memory improvements for users working in large repositories, with two related changes:
  • Metadata is now fetched sparsely with on-demand blob resolution, so only the data you actually need is fetched.
  • New content detection now uses transcript byte size instead of line count, which is more accurate and avoids unnecessary work.
• go-git/v6 has recently introduced a new LazyIndex which more efficiently handles idx and rev files, resulting in a lower memory footprint when interacting with large repositories. The Entire CLI has been upgraded to go-git/v6, to benefit from this and other improvements made since v5 was last released. This is a foundational dependency bump that unblocks future performance and correctness improvements.

Checkpoints in Remote Repos

• You can now store your entire/checkpoints/v1 branch in a separate dedicated repository, keeping your working repo's history clean while still giving you full checkpoint access across clones and teams.

Further Improvements

Agent Updates and Fixes

• External agent plugins are now auto-discovered during entire enable, entire rewind, and entire resume, with no manual config needed.
• Gemini CLI 0.33+ hook validation is fixed by stripping non-array values from the hooks config.
• Cursor 2026.03.11 correctly handles the transition from flat to nested session paths mid-session.
• Factory AI Droid now falls back to script parsing when the prompt isn't available through hooks.

Commit History Alongside Checkpoints

• Your Checkpoint history now shows all commits on a branch, including commits without Checkpoints. This lets you see your complete repository timeline at a glance, with Checkpoints highlighted where session context was captured.

entire trace Performance Insights

• We added a new diagnostic command to help report performance issues. If something feels slow during a session, entire trace gives you a clear breakdown to pinpoint what's causing it.

entire rewind Subdirectory Fix

• entire rewind now correctly resolves file paths when invoked from a subdirectory of the repo, rather than only working from the root.
  • Thank you to @mvanhorn for reporting and fixing this!

entire update Mise Detection

• entire update now correctly detects when the CLI was installed via mise, and suggests the right update command accordingly instead of giving a generic fallback.
  • Thank you to @mvanhorn for this fix as well!

That's all for now, rebels. As always keep the feedback coming our way, and if you have any questions, we're around on Discord. We hope you have a great rest of your week!

Boop.

We're a remote-first company, but every six months we bring our regional teams together for a Hack Week in-person to build, tinker, and collaborate face-to-face. This week, we gathered in Melbourne, Seattle, and Lisbon. Three cities. 25 Entirons. Many agents. Lots of ideas taking shape.

We also welcomed another agent to the alliance this week: the GitHub Copilot CLI, now equipped with checkpoints, resume, rewind, transcripts, and model tracking. Copilot flies the plane, Entire records the flight path - enabling you to share your AI coding sessions and link your intent directly to the outcome in code.

That'll do it for this week, rebels. As always, keep your contributions, PRs, stars and feedback coming. More ships and improvements coming your way next week.

Boop.

In a world with many agents, we believe your context — from chat sessions to logs and prompts — should automatically sync to the Git repository. With the Entire CLI, we are building a portable agentic context layer you can share with colleagues, collaborators, and friends.

With your help, this week we pushed a new Factory AI integration 🎉, created a new Repositories section on entire.io that lets you see all your org's repos, introduced a new external agent plugin system to help you bring your favorite agents to the Entire CLI, and lots of smaller improvements 👇

Agent Plugin System

• We're making it easier to integrate third party agents without forking the CLI. Agents can now run as standalone programs that follow a simple protocol, allowing them to be discovered on your system and used alongside built-in agents.

entire.io User Interface Updates

• See recently used repos in the sidebar and pin your most important ones for quick access.
• The checkpoints list now has more compact single-line rows for easier scanning grouped by day.
• A new breadcrumb header now lets you browse between commits within a Checkpoint.

Faster Hook Performance

We've heard your feedback. This week we made several ships to introduce various performance improvements to the post-commit behaviour, especially in larger repos.

• Replaced slow in-memory tree comparisons with native git operations, reducing hook latency on large repos.
• Added structured performance instrumentation. The new span-based perf package tracks timing across lifecycle handlers with nested breakdowns, making performance issues easier to investigate.
• To eliminate redundant calls in the prepare-commit-msg hook, staged file lists are now cached across sessions, and go-git's worktree.Status() (which scans all files) was replaced with native git diff --cached.
• Replaced O(N) go-git tree walks with git diff-tree in post-commit hook for faster commits.

Further Improvements

Updates to Cursor, Factory & OpenCode Agents

• Cursor now has full transcript analysis, enabling prompt extraction for shadow branch commit messages, summary extraction, and transcript position tracking.
  • Session metrics, including duration, turns, model name, and attribution, are now captured via hooks.
    • Thank you to @MarkoTatic for the detailed Cursor bug reports that helped drive these improvements!
• OpenCode sessions now end cleanly on quit via server.instance.disposed instead of lingering as active.
  • Thank you to @petrenk0n for reporting the empty sessions issue!
• An E2E test runner was added for Factory Droid sessions with full interactive flow coverage.
  • Thank you to @SvenMeyer for requesting Droid support!

Squash Merge Resume & Rewind

• entire resume parses all trailers, deduplicates sessions by ID, and sorts by timestamp to restore the correct state.
• entire resume on squash commits shows only the latest checkpoint instead of a confusing list of all sessions across the branch.
• entire rewind is fixed to pick the latest checkpoint in squash-merged commits, not just the first regex match.
• entire rewind is now able to handle squash commits properly.

Model Tracking in Checkpoints

• Checkpoints now capture which LLM model was used, persisted to metadata.json and visible in session info. The model is resolved from agent-specific hook payloads (Claude Code's SessionStart, Gemini CLI's BeforeModel).

Session & Hook Reliability

• Stale sessions are now properly cleaned up instead of lingering indefinitely.
• Fixed a bug where hooks could silently skip files that should have been tracked across turns.
• entire explain no longer hangs on repos with many checkpoints.
• Corrected inconsistent terminal behavior across different hook paths.
  • Thank you to @dismory for reporting the worktree config issue!

Setup & Developer Experience

• entire enable now supports --absolute-git-hook-path to set up git hooks with absolute paths to the entire binary, useful for environments where PATH resolution varies between shells or CI runners.
• Commit signing no longer breaks the test suite for contributors who have it enabled globally.
  • Thank you to @erezrokah for catching this and contributing the fix!

Thanks for all your help this week, rebels. Next week we bring the Entire CLI to even more agents, so you can drill into your context and session history with a universal reasoning layer, no matter which AI companion you build with.

Boop.

In a world where prompts are the new programming language, why not share them like code? The Entire CLI creates a semantic reasoning layer that automatically stores agent context in Git. Resulting in what we call, Checkpoints!

With help from the community, we shipped several improvements this week, including support for our first IDE. Today, we're bringing the Entire CLI to Cursor, enabling users to bind agent context to every push and explore, trace and share their intent. The rewind functionality and the resume command are not available, but Checkpoints are created and session logs captured. Thank you to @9bany for your early contributions to make this possible!

Here's what else changed:

OpenCode Support

• Since this week, the Entire CLI supports OpenCode.
• Fixed an issue with OpenCode and OpenAI Codex models not creating checkpoints when existing files were changed.
  • Thank you to @jaxondk for requesting OpenCode support, and to @ammarateya, @Avyukth, and @MementoMori123, whose OpenCode PRs helped validate the design!

Faster Checkpoints

• Introduced caching and optimized work tree updates to improve performance on Git commits and Git pushes.
• Squash-merged commits with multiple entire-checkpoint trailers correctly link to all their checkpoints on entire.io.
  • Thank you to @FSM1 for reporting the squash+delete workflow gap!
• To fix carry-forward false positives, orphaned shadow branches are no longer created when a user replaces agent content.
• Stale sessions no longer incorrectly condense into every commit.
  • Thanks to @BootstrapBits for the detailed concurrent session race analysis!
• Stuck checkpoint IDs and "no active sessions" errors are resolved.
  • HT @lakson-llc, @daeshawnballard, and @wmurphyrd!
• O(depth) tree surgery replaces O(N) flatten-and-rebuild for both metadata branch and shadow branch writes
• Extracted magic numbers to named constants for improved code quality.
  • Thanks to @ishaan812!

Further Improvements

• Web viewer
  • Added a searchable breadcrumb combobox making it easier to search and switch repos within the org.
  • In the spirit of the community, public repos are available on entire.io without logging in!
  • Fixed the tool calls section to be hidden for agents that don't report them.
  • False positive trail merge detection is fixed for new branches.
• Fresh clone support
  • entire enable now creates local metadata branch from remote when available, preserving checkpoints on fresh clones
• Linking commits to your checkpoints
  • The checkpoint linking question when doing git commit -m "commit message" now has an "Always" option.
• Depreciating "Auto-Commit"
  • To reduce complexity and with feedback from the community, we decided to cut the auto-commit command. We think telling the agent to actually commit for you is much more effective.
• Hook Scoping
  • Entire only creates .entire/logs/ folders in repos where Entire is enabled. Git hooks only run in repos where Entire is enabled.
    • Thanks to @knowsuchagency!
• Secret Redaction
  • Secret redaction is improved to not redact legitimate code.
• Unicode and Internationalization
  • UTF-8 truncation no longer produces garbled text for CJK/emoji characters.
    • Thanks to @wasabeef for identifying the root cause!
• Session Hygiene
  • Gitignored files (e.g. node_modules) are no longer tracked in session metadata.
  • Resume sessions are now sorted by creation time and stale session files are automatically cleaned up.
• Nix Package
  • Entire is available as a Nix package: nixpkgs/entire.
    • Thanks to @evanlhatch for requesting this and @DieracDelta for the interim fork!

Keep the contributions coming. Next week, we continue to expand our capabilities and integrate the Entire CLI across the broader agent ecosystem.

That's all for now, rebels.

Boop.

Last week, we introduced Checkpoints to the world — our first primitive designed to tackle one of the biggest problems in agent-driven development: context. Today, conversations, reasoning, and file changes are fragmented or lost between sessions. As agents generate hundreds or even thousands of lines per interaction, that context loss compounds quickly. Agents retrace steps, duplicate reasoning, waste tokens, and lose the thread of decisions made hours or days earlier.

To bridge this gap, the Entire CLI automatically captures agent sessions, creating a semantic reasoning layer that binds agent context to Git on every push. Resulting in what we call Checkpoints. This week we focused on making the Entire CLI easier to integrate with other agents, including a refactor that simplifies how external tools plug into the workflow and interact with grouped changes. Stay tuned, new agent support shipping very soon.

And with your help, we shipped a variety bug fixes, performance improvements, and key updates:

Expanding Agent Integrations and Capabilities

• The Entire CLI codebase has a stronger multi-agent framework, enabling faster integration of new agents.
• The Entire CLI integration with the Gemini CLI supports full transcript parsing, Checkpointing, and session explanations.

Secret Detection

• Checkpoints runs layered secret scanning using gitleaks patterns combined with entropy analysis.
• Secrets are redacted across all persistence paths — including shadow branches, metadata, and condensed logs — ensuring sensitive data does not leak into Git history.
  • Thank you to Hi120ki, andreidavid, and Pythoninthegrass!

Smarter Hook Management

• Hook installation is more resilient, with automatic resolution of hook directories supporting worktrees and custom configurations using git --git-path hooks.
• Existing Git hooks that the Entire CLI does not recognize are preserved.
• External hook managers such as Husky or Lefthook are detected during entire enable, with a warning before anything is overwritten.
  • Shout out to AlienKevin, Camwest, SchutteJan, and FSM1!

Checkpoint Reliability

• Subagent task file modifications are correctly captured in Checkpoints.
• Deleted files in task Checkpoints are properly tracked.
• Each Checkpoint produces exactly one commit, eliminating noise in Checkpoint history.
• Git-ignored files such as node_modules are no longer tracked in session metadata.
  • Danke, BootstrapBits!

Improved entire enable

• The setup experience has been redesigned with clearer prompts and better defaults, making it faster and more intuitive to get started in a new repo.
  • Big thank you to Jayanth-iyer, TyceHerrman, and Marcodicro-dp!

Session Restore Fixes

• Sessions that previously failed to restore after repo changes (stash, pull, rebase) recover correctly.
• Full Checkpoint history is preserved across branch operations.
  • HT, Jaydenfyi!

Empty Repo Support

• Improved messaging when the Entire CLI is used in a freshly initialized repository that has no commits yet.

In the coming week, we’ll focus on integrating the Entire CLI across the broader agent ecosystem — so every developer can have pluggable, independent context natively tied to their Git repository, no matter which agent they use.

Boop.

This week we launched Checkpoints, our new primitive that automatically captures agent context as first-class, versioned data in Git. It's our first crack out the gate at building a universal semantic reasoning layer for every agent. Thanks for the love, feedback, the stars, and PRs. With your help, we've shipped new features, improvements, and bug fixes to the Entire CLI and web UI. Here's a few of our favorites:

• We've improved Google Gemini CLI support — explain, rewind, and resume now work with Gemini sessions.
• Layered secret detection using gitleaks now patterns on top of entropy-based redaction, strengthening protection against accidental credential leaks and reducing risk in every commit.
• Git hooks can now chain with existing hooks. Break less, keep working the way you expect.
• On entire.io, we made the Checkpoint view easier to navigate by bringing session logs and code diffs into a single, unified view.

And of course, that's just a few transmissions. For various more bug fixes & improvements — see more changes to the Entire CLI here.

This is it for this round. New dispatch every week. Boop.

*TLDR: Today, we are announcing our new company, Entire, backed by a $60 million seed round to build the world's next developer platform. We are also shipping our first product as open source CLI to tie agent context into Git on every push.*

The game has changed. The system is cracking.

In the last few months alone, the fundamental role of a developer has been refactored. From Anthropic's Claude Code with Opus 4.6, to OpenAI's latest GPT-5.3-Codex agentic coding model, to Cursor's Composer 1.5 and more, advancements in agentic intelligence have turned the flow of coding on its head. The terminal is becoming the new center of gravity, as developers prompt fleets of agents across multiple terminal windows at once. Spec-driven development is becoming the primary driver of code generation. Agents now interoperate in parallel, generating and evaluating hundreds of variants simultaneously. As a result, massive volumes of code are being generated faster than any human can reasonably understand.

Yet today, we still rely on a software development lifecycle built before the era of the cloud, inherently designed for human-to-human collaboration. And the cracks are forming. Issues were designed for human planning and tracking, not as structured, machine-readable units of work. Git repositories were never extended to version everything developers build with in the AI era. Pull requests simply do not scale for large monorepos. Every day, agents are being choked and throttled by centralized API capacity and rate limits. The truth is: the entire software ecosystem is being bottlenecked by a manual system of production that was never designed for the era of AI in the first place. A system that cannot be retrofitted for what's ahead.

Just like when automotive companies replaced the traditional craft-based production system with the moving assembly line, we must now reimagine the entire software development lifecycle for a world where machines are the primary producers of code. Creating the assembly line for the era of agents.

Announcing Entire: The world's next developer platform

This is the purpose of our new company Entire, to build the world's next developer platform where agents and humans can collaborate, learn, and ship together. A platform that will be open, scalable, and independent for every developer, no matter which agent or model you use.

Entire will be based on three key components: a git-compatible database that unifies code, intent, constraints, and reasoning in a single version-controlled system; a universal semantic reasoning layer that enables multi-agent coordination through the context graph; and an AI-native software development lifecycle to reinvent agent-to-human collaboration.

In pursuit of this vision, we are proud to be backed by a $60 million seed investment led by Felicis, with support from Madrona, M12, Basis Set, 20VC, Cherry Ventures, Picus Capital, and Global Founders Capital. Entire is further backed by a slate of international investors including Gergely Orosz, Theo Browne, Jerry Yang, Olivier Pomel, Garry Tan, and others—who all understand that software development is ready for its next platform shift.

Our first release: The Entire CLI to track agent context

Today, agent sessions are ephemeral. Prompts live in terminals and reasoning lives in context windows. The decisions, constraints, and iteration that produce code disappears the moment you close the session. Git preserves what changed, but nothing about why. With agents generating hundreds or thousands of lines per session, this context loss compounds fast. Without shared context, agents can't collaborate effectively. They retrace steps, duplicate reasoning, waste tokens, and lose the thread of decisions made hours or days earlier.

Our first ship makes that missing context durable:

Checkpoints are a new primitive that automatically captures agent context as first-class, versioned data in Git. When you commit code generated by an agent, Checkpoints capture the full session alongside the commit: the transcript, prompts, files touched, token usage, tool calls and more. This context becomes the foundational write-path of our semantic reasoning layer. You can browse checkpoints by branch, drill into individual sessions, and trace how your codebase evolved through human-and-agent collaboration commit by commit.

Our plan is to support Checkpoints for every agent. Today, Entire CLI ships with support for Anthropic's Claude Code and Google Gemini CLI. Codex, Cursor CLI, and other agents coming soon.

How it works

Checkpoints run as a Git-aware CLI. On every commit generated by an agent, it writes a structured checkpoint object and associates it with the commit SHA. The code stays exactly the same, we just add context as first-class metadata. When you push your commit, Checkpoints also pushes this metadata to a separate branch (entire/checkpoints/v1), giving you a complete, append-only audit log inside your repository. As a result, every change can now be traced back not only to a diff, but to the reasoning that produced it.

Checkpoints are useful immediately:

• Traceability - inspect the reasoning behind any agent-generated change
• Faster Reviews - review intent and constraints, not just diffs
• Better handoffs - resume work without replaying prompts or sessions
• Less token waste - agents stop repeating mistakes that you corrected in past sessions
• Multi-session and agent support - support for concurrent agentic sessions

Getting Started

The best part is that you can set up Entire in two easy steps.

Then navigate to your repository and run entire enable — follow the prompts to configure Entire for that project. That's it. Your agent sessions are captured automatically - in a structured and ready-to-use format.

No more stealth. We are building in the open!

Checkpoints are our first step towards building a universal semantic reasoning layer for agents. Today, it gives you traceability and history. Tomorrow, it will become the shared memory that allows agents to coordinate, hand off context and build together without collision or loss of understanding.

Most importantly, we're releasing the Entire CLI open source project because we believe that this layer should be portable, independent, and available for every single agent or model. And because we know, we are better with the contributions of the interconnected community of open-source developers.

Our roadmap will be directly paved by your feedback, in Discord and in GitHub Discussions. We're ready for it. See you there.