re_gent: a step log and blame layer for Claude Code, Codex and OpenCode sessions
Version control for AI agents — track what your agent did, blame any line to a prompt, inspect any step.
At a glance
- What is it?
- re_gent records every tool-using turn an AI coding agent takes into a content-addressed store under .regent/, then exposes it through three commands: log, blame and show. The idea is sound and the scope is narrow, but the README stops short of documenting retention, storage growth and how the hooks behave when two agents edit the same file.
- Who is it for?
- Adopt re_gent if you run Claude Code, Codex CLI or OpenCode on a repository where you regularly need to answer which prompt produced a line, and if you are willing to accept that .regent/ is a second store you now have to think about. Do not adopt it if your agents run outside those three tools, or if you need a documented retention policy before the store starts growing.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 76 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap re_gent is aimed at: agent edits with no history behind them
Git records what a human committed. It says nothing about the sequence of tool calls that produced the working tree. When an agent rewrites a handler and you notice three hours later that a method check disappeared, git will show you a diff against the last commit, but not which prompt asked for the change, which tool applied it, or what the agent was told beforehand. The README frames this as a list of familiar complaints: "It was working five minutes ago", "Why did you change that file?", "Go back to before the refactor". Those are not new problems. What is new is that the edits arrive faster and with less human attention per edit.
The intended user is a developer already running an agentic coding tool on a real repository, who wants a per-step record without writing commits by hand. The README is explicit that no manual commits are needed and that activity is tracked automatically once rgt init has run. That is the whole pitch. It is not a replacement for git, and the README does not claim it is.
Steps, a DAG, and a .regent/ directory that mirrors .git/
The storage layout is the clearest part of the README. re_gent writes into .regent/, which it describes as being like .git/: an objects/ directory of content-addressed blobs hashed with BLAKE3, a refs/ directory holding one session pointer per agent, an index.db SQLite query index, and a config.toml. The README does not document the config.toml keys, which is a gap for anyone who wants to change where the store lives or how long it keeps data.
The unit of record is a Step. The README gives the structure directly: a parent hash, a tree representing a workspace snapshot, a causes array of tool invocations each carrying tool_name, args and result, a session_id, and a timestamp. Steps form a DAG, each session gets its own branch, and common ancestors dedupe. That dedupe matters: if two sessions start from the same tree, the shared portion is stored once. The tool_name and args fields are what make blame possible, because the prompt text is carried alongside the tool call rather than reconstructed later.
The README points to POC.md for the full specification. Nothing in the supplied material describes how the workspace snapshot is taken, whether it is a full tree or a diff against the parent, or how conflicts between concurrent sessions are resolved. Those are the questions that determine whether the store stays manageable.
Installing rgt and the four commands that carry the tool
Two install paths are documented. Homebrew: brew tap regent-vcs/tap followed by brew install regent, which the README says installs the rgt command and sets up shell completions for bash, zsh and fish. Or Go: go install github.com/regent-vcs/regent/cmd/rgt@latest. Manual completion setup is given for all three shells, for example rgt completion zsh > "${fpath[1]}/_rgt". Pre-built binaries are on the releases page, and the source build is git clone followed by go build -o rgt ./cmd/rgt.
Once installed, the workflow is three lines. cd your-project, then rgt init, then work with Claude Code, Codex or OpenCode as normal. The README states that hooks auto-configure on rgt init and that no manual setup is required. It does not say which files those hooks write to, which is the first thing I would want to check before running this on a repository I care about.
The command surface is small. rgt log shows step history and accepts --session, -n, --json and --graph. rgt blame takes a file and line, as in rgt blame src/file.go:42, and returns the step hash, session, tool, and the prompt text that produced the line. rgt show takes a step hash and prints the parent, session, timestamp, tool, file, the changed lines, and the surrounding conversation. rgt sessions lists active agent sessions with a step count and a last-activity time, and rgt log --session filters history to one of them. The truncation in the supplied README cuts off mid-table at rgt sess, so there may be commands beyond these four that I cannot confirm.
What blame actually returns, and why the conversation field matters
The blame output in the README is worth reading closely because it shows the design decision that separates re_gent from a plain audit log. For a given line, it prints the step hash, the session identifier in the form claude_code:claude-20260502-143021, the tool, and the prompt: "Add error handling to the request handler". The session identifier encodes both the agent and a timestamp, so you can tell at a glance which tool produced a change and roughly when.
The show command goes further and prints the conversation around the step, with a User turn and an Assistant turn. That is the part that would actually settle an argument about why a line exists. A diff tells you what changed. A prompt tells you what was asked for. The assistant reply tells you what the agent believed it was doing, which is often where the misunderstanding is visible.
The trade-off is that storing conversation turns alongside file snapshots is expensive in a way a plain diff is not. Nothing in the supplied material quantifies that, and I would not guess at a number. If you plan to run this continuously, measuring the size of .regent/ after a day of real agent work is the first experiment worth doing.
Three supported agents, and the rest are planned
The compatibility table lists Claude Code, OpenAI Codex CLI and OpenCode as fully supported. Cursor, Cline and Continue are listed as planned. That is a narrow integration surface, and it is the main constraint on who can use this today. If your team standardises on Cursor, re_gent will not record anything for you, and the README gives no timeline for when it will.
The multi-session example is the most interesting documented behaviour, because it implies the hooks are agent-aware rather than generic. The sessions output shows a claude_code session and a codex_cli session tracked side by side with independent step counts, and rgt log --session filters to one of them. What the README does not describe is what happens when both sessions edit the same file. Each session has its own branch in the DAG, and the README says common ancestors dedupe, but concurrent edits to the same path are a different problem from shared ancestry. That case is undocumented, and it is the one most likely to produce a confusing blame result in practice.
The maintenance question the README does not answer
The release history is short and recent: v0.2.0 and v1.0.0 both in May 2026, then v1.1.0 in June 2026, with the last push in July 2026. That is a project moving quickly through its early versions, which cuts both ways. Fixes arrive fast. So do breaking changes, and a v1.0.0 landing two weeks after v0.2.0 suggests the storage format was still settling. Anyone storing months of agent history in .regent/ should assume the on-disk format may change between minor versions, and the README does not describe a migration path or a format version field.
Retention is the other open question. There is no documented command for pruning old steps, no stated default for how long history is kept, and no mention of what happens when index.db grows. Since every tool-using turn creates a step, a long agent session on a large repository produces a lot of objects. The README does not address this at all, and I would treat it as unverified rather than assume a garbage collection mechanism exists.
The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive choice consistent with the Go tooling ecosystem. It also means there is no copyleft obligation if you embed rgt in an internal pipeline. This is not legal advice; read the LICENSE file and the NOTICE requirements yourself if you plan to redistribute a modified build.
How this differs from capturing agent transcripts or using git alone
The obvious alternative is to log agent sessions yourself: Claude Code and similar tools write transcripts to disk, and a script can archive them next to the repository. That approach records the conversation but not the mapping from a conversation turn to a specific line in a specific file. You can read what the agent was asked, but you cannot run blame on line 42 and get an answer. re_gent's contribution is that mapping, and it is the reason the step structure carries both a tree and a causes array rather than just a transcript.
The second alternative is git itself, with a commit after every agent turn. That gives you real history and real diffs, using tools everyone already has. The cost is that it pollutes the commit graph with machine-generated commits, and it forces a commit at turn boundaries that may not correspond to anything meaningful. The README's framing is that agents need their own store rather than more commits, and the .regent/ layout is a direct expression of that choice. Whether a separate store is better depends on whether you want agent history in the same graph as human history or deliberately kept apart. re_gent picks apart, and that is a defensible position, but it means .regent/ is a second thing to back up and a second thing to add to .gitignore if you do not want it committed.
Editorial conclusion
Adopt re_gent if you run Claude Code, Codex CLI or OpenCode on a repository where you regularly need to answer which prompt produced a line, and if you are willing to accept that .regent/ is a second store you now have to think about. Do not adopt it if your agents run outside those three tools, or if you need a documented retention policy before the store starts growing. Verify three things first: whether rgt init is safe to run on a repository that already has uncommitted agent edits, how large .regent/ grows over a working day of agent activity, and whether the hooks still record correctly when two sessions touch the same file inside the same minute.
Community notes