Atlas: A Black Box Recorder for AI Agent Code Changes
> Original repo: pacifio/atlas · Rust · MIT · +895 stars in a single day (2026-09-02)
A Chilling Question
You asked Claude Code to refactor an auth module. It finished cleanly with a tidy commit message. Three months later, a token-refresh deadlock appears in an edge case. git blame shows the line was written by an agent, with the commit message "fix: handle token refresh edge case".
Then what? Nothing. The agent's reasoning, the files it read, why it chose this approach over another — all evaporated when the terminal closed. Git records *what* changed, but not *why*.
pacifio/atlas targets exactly this gap. Its positioning is direct: source control for agents — version control for agent-written code that also captures the entire thought process behind the code.
Checkpoints: A Black Box for Commits
Atlas's core concept is the checkpoint. A checkpoint binds four things together:
1. prompt — what you asked 2. tool calls — which tools the agent called, with what arguments 3. file changes — what was modified 4. reasoning — the agent's chain of reasoning
All of it is stored in a SQLite database in the project's .atlas/ directory. Key design choice: secrets are scrubbed on write — sanitized before hitting disk, not before uploading. Atlas is fully local by default: no account, no network.
A notable detail: checkpoint links survive rebases and amends. Atlas uses patch-id reconciliation — when a rebase rewrites history, it re-associates commits with sessions via patch content hashes. If a squash makes the link truly ambiguous, it chooses to orphan rather than guess. This is more rigorous rebase handling than most git tooling.
Parallel Agents: Shared Memory, Not Shared Context Windows
Atlas also lets multiple agents work in parallel on the same codebase. Claude Code, Codex, Atlas's own Rust-based Cersei agent, and any agent in the ACP registry (Cursor, OpenCode, Kilo Code, etc.) run in the same interface.
Atlas doesn't try to build a universal agent. Instead it provides an agent-agnostic context layer. All agents connect via ACP (Agent Client Protocol) through a single send path. Before messages reach an agent, Atlas performs five layers of context injection:
| Injection | Source | Timing |
|---|---|---|
| @ mentions | Local Rust parser: files, folders, symbols, branches, commits, notes, papers, past sessions | Every turn |
| Shared agent memory | Active plans, decisions, file changes, failures, architecture notes written by any agent | Every turn |
| Semantic matching | Messages embedded locally, matched against project memory via HNSW search | Every turn |
| Session handoff | Curated fact pack + tail of previous session, even if run by a different agent | First message |
| Existing docs | CLAUDE.md, AGENTS.md, Claude Code memory files, Codex history, folded into one index | Continuous |
This means decisions made by Claude Code are visible to Codex in the next session, and vice versa — not via a shared context window (which would explode), but via a local semantic index.
A clever detail: @-mentioning a 5,000-line file sends the agent a *path*, not the content. The agent reads it on demand, so one mention doesn't occupy the context window for the whole session.
Why It's Gaining Traction
+895 stars in one day isn't the top of GitHub Trending, but for a macOS-first desktop app (built with Tauri; Linux/Windows from the same codebase but untested), it signals a real pain point.
The pain point: agent-written code is exploding, while auditability is near zero. Picture a team of five developers, each shipping 2,000 lines a day via Claude Code. A month later, 300,000 lines of agent code. Bugs appear; git blame just says "Claude Code". No prompt history, no file access trail, no rationale.
This isn't hypothetical — it's the reality of many teams in 2026. Atlas is essentially building auditability infrastructure for agent-written code.
Relationship with Git: Enhancement, Not Replacement
Atlas is not another git. It depends on git and adds a layer of "reasoning metadata" on top. You can commit with any tool — terminal, another editor, even with Atlas closed — and it will associate commits back to sessions by observing git history.
The key design choice: Atlas doesn't intercept commits, it observes them. You change nothing about your existing workflow. Atlas works passively in the background.
A Thoughtful Architectural Choice
Atlas stores session data in SQLite rather than markdown or JSON. The README explains: "because it is queried, not read". Session data is large, structured, and queried in many patterns (by time, file, agent, keyword) — SQLite beats a pile of markdown files. Meanwhile, the knowledge base (human-written notes) remains markdown, because that's meant to be read.
Match storage medium to usage pattern — a simple principle many tools get wrong. Atlas layers correctly here.
Limitations and Open Questions
- macOS-first: Linux and Windows build from the same Tauri code but are "untested", limiting the audience.
- ACP dependency: agents must support ACP. Claude Code and Codex are the "most-tested path"; other registry agents have "QA ongoing".
- Local-first cost: team collaboration requires signing in to create an organisation for sync; conflict resolution for local SQLite isn't detailed.
TL;DR
Atlas gives agent-written code a black box — not a git replacement, but an auditability layer on top of git answering "who changed what, when, and why". As agent-written code grows, someone had to build this infrastructure. Atlas's timing looks right.
GitHub: https://github.com/pacifio/atlas Docs: https://docs.tryatlas.cc/