re_gent: version control for AI agents, with blame that points at a prompt

The gap re_gent targets: agents write code and leave no history

An AI coding agent edits files directly. Git records the resulting bytes, but it records them as your commit, under your name, with no link to the prompt that asked for the change. When a refactor goes wrong three turns later, the diff shows what changed and nothing about why.

re_gent is a Go command line tool that closes that gap. The README frames the problem as a list of complaints a developer actually says out loud: "It was working five minutes ago", "Why did you change that file?", "Go back to before the refactor". Those are version control questions, and the project's argument is that agents were given write access to codebases without the tooling that makes write access recoverable.

It is aimed at people running agentic coding tools on a real repository, not at researchers logging model calls. The audience is narrow on purpose: the supported tools are Claude Code, OpenAI Codex CLI and OpenCode, all marked fully supported, while Cursor, Cline and Continue are listed as planned. If you use something outside that set, the README gives you nothing to work with.

How re_gent stores agent activity: steps, a DAG and a SQLite index

re_gent keeps its data in a .regent directory at the root of your project, and the README draws the parallel to .git directly. That directory holds four things: objects, described as content-addressed blobs hashed with BLAKE3; refs, described as session pointers, one per agent; index.db, a SQLite query index; and config.toml.

The unit of history is a Step. The README shows its shape in Go: a parent hash pointing at the previous step, a tree holding a workspace snapshot, a causes array containing the tool name, its arguments and its result, a session_id, and a timestamp. Every tool-using turn produces one of these, which is why the demo caption says no manual commits are needed.

Steps form a DAG rather than a linear log. Each session gets its own branch, and common ancestors are deduplicated. That is the mechanism behind rgt sessions, which lists concurrent sessions side by side with a step count and a last-activity time, and behind the --session flag on rgt log.

The dependency list in go.mod is consistent with that design: lukechampine.com/blake3 for hashing, modernc.org/sqlite for the index, sabhiram/go-gitignore for deciding what to skip. Note that modernc.org/sqlite is the pure-Go SQLite build, so there is no cgo requirement implied by the module file. The README points to POC.md for the full specification, and that file exists at the repository root.

Installing re_gent and running rgt init in an existing project

The README gives two install paths. Homebrew is the first, and it also sets up shell completions for bash, zsh and fish:

brew tap regent-vcs/tap
brew install regent

The second is a Go install, which requires Go 1.23.0 or later according to go.mod:

go install github.com/regent-vcs/regent/cmd/rgt@latest

Both install a binary named rgt, not re_gent. That naming split is worth internalizing early, because every command in the README uses the short form. There is also a from-source route (clone, then go build -o rgt ./cmd/rgt) and pre-built binaries on the GitHub releases page.

Once rgt is on your PATH, move into your project and initialize:

cd your-project
rgt init

According to the README, rgt init creates the .regent directory and auto-configures hooks for the supported tools. That is the whole setup: you then work with Claude Code, Codex or OpenCode as usual, and activity is captured without manual commits.

To confirm something was recorded, run rgt log. The README's example output shows one block per step, with a short step hash, a relative time, the tool name, the file touched and a line count:

rgt log

The first real use is blame. The README's example takes a file and a line number and prints the step hash, session, tool and the prompt text:

rgt blame src/handler.go:42

That output is the point of the tool. It answers which prompt wrote this line, and it does so from recorded data rather than from your memory of a chat window.

Where re_gent gets in the way, and when it is the wrong tool

The most obvious limitation is that the README does not document a revert, checkout or restore command. The command table covers init, log, sessions, blame and show, and the Quick Start stops at inspection. The project's own framing includes the wish "Go back to before the refactor", but the documented surface lets you see the step and read its diff, not roll the workspace back to it. Treat re_gent as an audit and forensics layer, not as an undo button.

The second limitation is scope. Support is limited to Claude Code, Codex CLI and OpenCode. Cursor, Cline and Continue are listed as planned, and the README does not say when. If your team's agent runs in an editor outside those three, rgt init has nothing to hook into.

Third, this is a young project with a fast-moving interface. It reached v1.0.0 in May 2026 and v1.1.0 in June 2026, with the last push to main on 2026-07-02. Two minor releases in the first month after 1.0 is normal for a project finding its shape, but it also means the storage format and the command surface are not yet settled by long use. The README does not describe a migration path for the .regent directory between versions, and the README does not document rollback.

Finally, .regent stores workspace snapshots. The README does not state a size bound, a pruning command or a retention policy, so a long-running session on a large repository is a disk question you will have to answer yourself by watching the directory.

re_gent versus git and versus replaying the chat transcript

The honest comparison is not re_gent against git, because they record different things. Git commits the state of your tree when a human decides to commit. re_gent records each tool-using turn as it happens, with the tool arguments, the result and the session that produced it. A git blame tells you which human touched a line and when. An rgt blame tells you which step and which prompt produced it. On a repository where an agent did most of the writing, the second question is the one you actually have.

The other alternative is the one most people use today: scroll back through the agent's chat transcript. That works for one session and fails for several, which is exactly the case rgt sessions is built for. The README's example shows a claude_code session and a codex_cli session listed together with step counts and last-activity times, and rgt log --session filters history to one of them. A chat window has no equivalent, because the transcript lives inside one tool.

The cost of re_gent's approach is that it duplicates state. You now maintain a .git directory and a .regent directory, and the second one is not something your existing review process understands. That is a real trade, and it is the reason the tool is worth adopting only when agent-authored changes are common enough that reconstructing them by hand has already cost you time.

Licence, upgrade cost and what the repository tells you about maintenance

re_gent is licensed under Apache-2.0, per the licence badge and the LICENSE file at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant, which matters if you are embedding the tool in a commercial workflow. It also means you can fork the project if the maintainers stop. This is a description of the licence text, not legal advice; your own counsel decides how it applies to your distribution.

Upgrading is a Go build away. The Makefile stamps version, commit and date into the binary through ldflags pointing at internal/cli, and .goreleaser.yaml mirrors that stamping for release builds. So rgt --version should report a real version rather than a placeholder. Homebrew installs move with the tap, and go install ...@latest picks up the newest tagged release.

The maintenance signal is mixed but readable. The repository is not archived. The last push to main was on 2026-07-02, which is under three months before the date of writing, so the project is not dormant. The release cadence is two minor versions in 2026, v1.0.0 in May and v1.1.0 in June. What the repository does not show is a stable interface promise: the README does not document a storage-format version, and POC.md is described as the complete specification, so a format change would land there first. Pin a version in CI rather than tracking @latest if you depend on the .regent directory surviving an upgrade.

Editorial conclusion

Adopt re_gent if you already run Claude Code, Codex CLI or OpenCode on a codebase and you need to answer which prompt produced a given line without replaying a chat log. Do not adopt it if you need to undo an agent's work: the command table in the README lists log, blame, show and sessions, and it does not document a revert or checkout. Before trusting it, run rgt init in a scratch repository, let an agent make one edit, and confirm that rgt blame on that line names the step and prompt you expect.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. regent-vcs/re_gent on GitHub
5. Releases