> Original repo: pacifio/atlas · Rust · MIT · +895 stars in a single day (2026-09-02)
The unsettling question
You asked Claude Code to refactor an auth module. It finished, with a tidy commit message. Three months later, a production bug surfaces — a token refresh deadlock in an edge case. You git blame it, and the line was written by an agent, with a commit message like "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 of it vanished when the terminal closed. Git records *what* changed, but not *why*.
pacifio/atlas targets exactly this gap. Its positioning is blunt: source control for agents — version control for agent-written code that captures the entire thought process behind it.
Checkpoints: a black box for commits
Atlas's core concept is the checkpoint. It binds four things together:
1. prompt — what you asked 2. tool calls — which tools the agent invoked and with what arguments 3. file changes — which files changed and how 4. reasoning — the agent's reasoning chain
All of this lives in a SQLite database under the project's .atlas/ directory. A key design decision: secrets are scrubbed on write — before hitting disk, not before upload. Atlas is fully local by default: no account, no network required.
One notable detail: checkpoint links survive rebases and amends. Atlas uses patch-id reconciliation — when git rebase rewrites history, it re-associates commits with sessions via the hash of the patch content. If a squash makes the link genuinely ambiguous, it chooses to orphan rather than guess. That's more rigorous rebase handling than most git tooling.
Multi-agent parallelism: shared memory, not a shared context window
Atlas also lets multiple agents work in parallel on the same codebase. Claude Code, Codex, Atlas's own agent (built on the Rust Cersei framework), and any agent in the ACP registry (Cursor, OpenCode, Kilo Code, etc.) can run in the same window.
The design decision worth unpacking: instead of building one "universal agent", Atlas built an agent-agnostic context layer. All agents connect via the Agent Client Protocol (ACP) through a single send path. Before a message reaches the agent, Atlas injects five layers of context:
| 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 | Your message is embedded locally and matched against the project memory index via HNSW search | Every turn |
| Session handoff | Curated fact pack + tail of the 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 |
The implication: a decision made by Claude Code is visible to Codex in the next session. And vice versa. Agent memories are bridged not via a shared context window (which would explode), but via a local semantic index.
A clever detail: @-mentioning a 5000-line file sends the agent a path, not the file contents. The agent reads it when needed, so one mention doesn't occupy the context window for the rest of the session.
Why is it trending?
+895 stars in a day isn't the top of GitHub Trending, but for a macOS-first desktop app (built with Tauri; Linux/Windows builds exist from the same code but are untested), it signals a genuine pain point.
That pain point: agent-written code is growing fast, but auditability is nearly zero.
Picture this: a team of 5 developers, each writing 2000 lines a day with Claude Code. A month later, the codebase holds 300,000 lines of agent-written code. When a bug appears, git blame shows "Claude Code" commits. You don't know the prompt, the files read, or why the approach was chosen.
This isn't hypothetical — it's the real state of many teams in 2026. By binding those four artifacts together, 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. Whether you commit from a terminal, another editor, or with Atlas closed, it can associate commits back to sessions by observing git history.
The key design choice: Atlas doesn't intercept commits, it observes them. You don't need to change any existing workflow. Atlas works silently as a passive recorder.
A worth-pondering architecture choice
Atlas stores session data in SQLite rather than markdown or JSON. The README explains: "because it is queried, not read."
That's an engineering judgment. Session data is large, structurally complex, and queried in varied patterns (by time, file, agent, keyword) — SQLite beats a pile of markdown files. Meanwhile the knowledge base (human-written notes) remains markdown, because that *is* meant to be read.
Match the storage medium to the usage pattern — a simple principle many tools miss. Notion stores everything, including notes that should be markdown, in a database; many agent frameworks stuff everything, including structured session records, into markdown files. Atlas layers this correctly.
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 to be managed. Claude Code and Codex are the "most-tested path"; other registry agents have "QA ongoing".
- Cost of local-first: team collaboration requires signing in to create an organisation for sync. Conflict resolution for the local SQLite store isn't detailed.
One-line takeaway
Atlas puts a black box on agent-written code — not a git replacement, but an auditability layer on top of git answering "who changed what, when, and why". As the share of agent-written code keeps climbing, someone had to build this infrastructure, and Atlas's timing is good.
GitHub: https://github.com/pacifio/atlas Docs: https://docs.tryatlas.cc/