Atlas: checkpointing coding agent sessions against git commits
Source control for agents. Use multiple coding agents, track their changes and query them in one place
At a glance
- What is it?
- Atlas is a macOS Tauri desktop app that records agent sessions in a local SQLite database and links each commit back to the session that produced it. The idea is sound; the platform support and the long tail of ACP agents are where the caveats sit.
- Who is it for?
- Adopt Atlas if you already run Claude Code or Codex on macOS and want the prompt-to-commit link recorded without leaving the machine. Do not adopt it if you are on Linux or Windows, since the README states those build from the same Tauri codebase but are untested, or if you depend on a registry agent outside the well-tested ACP path.
- Can I use it commercially?
- Yes. MIT 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 received new commits within the last day.
- What is it written in?
- Mainly Rust, 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 Atlas targets: a commit message written by a model
The README states the problem directly. Agents write a share of the code and keep none of the reasoning behind it. The prompt, the tool calls, the approach tried first and abandoned, all of it lives in a scrollback buffer until the buffer scrolls. What survives is a commit message, written by a model, summarising a diff. Months later that is the only record of why the code looks the way it does.
Atlas names three consequences. Agents start from zero every session, so rebuilding context is the developer's job each time. Switching agents loses the thread, because Claude Code cannot read Codex's history and Codex cannot read Claude Code's. And context lives in ten places: a knowledge base, CLAUDE.md, AGENTS.md, and each agent's own memory files, with nothing reading all of them at once.
That third point is the sharpest one. The first two are inconveniences you can work around by pasting a summary into the next prompt. The third is a structural problem: every agent has invented its own memory format, and none of them read the others'. Atlas is aimed at engineers running more than one coding agent on the same repository, and at anyone who has had to explain a six-month-old change to a reviewer with nothing but a diff.
Checkpoints: sessions in SQLite, commits linked after the fact
A checkpoint is the unit Atlas adds to git. According to the README, Atlas records every agent session locally in .atlas/sessions.db, with secrets scrubbed before anything touches disk. When you commit, from any tool and even with Atlas closed, the commit is linked back to the session that produced it as a checkpoint. The README states that links survive rebases and amends.
The design choice worth noting is that the link is stored separately from git history. The checkpoint record, meaning which agent session produced which commit, is SQLite in the project's gitignored .atlas/ directory, and the README gives the reason: it is queried, not read. That is a deliberate split. Everything else the project writes is plain files. Notes are markdown, canvases are JSON, sessions are JSONL, and the editor is a file on disk, so the README claims you can close Atlas and pick up in vim. The checkpoint index is the one exception, and the justification is that you want to ask questions of it, such as which sessions touched this file, rather than read it start to finish.
The consequence is that the checkpoint graph does not travel with a clone. It is per-machine, per-project state under a gitignored directory. Onboarding a teammate means they start with an empty index unless they sign in and sync. The README does mention signing in and creating an organisation when you want to sync across a team, but the local path is the one described in detail.
How agents are run: ACP subprocesses and an in-process fork of Codex
Atlas does not reimplement the agents. The README states that Claude Code and Codex run as external subprocesses over ACP, the Agent Client Protocol from Zed, described there as the most-used, most-tested path. Atlas Agent, the project's native agent, runs in-process on a hard fork of the Codex engine, with CONTEXT.md and ADR-0004 cited for the details. Beyond those, Atlas can spawn any agent in the ACP registry, naming Cursor, OpenCode, and Kilo Code, and pulling in each one's official binary automatically. All of them go through the same send path.
That is a cleaner architecture than wrapping each agent's CLI with bespoke parsing, because the enrichment layer sits at one protocol boundary rather than at four. The README notes that QA on the long tail of registry agents is ongoing, which is the honest version of a caveat: the two named agents are the tested path, the registry is best-effort.
The memory layer is the part that makes the side-by-side claim meaningful. A decision Claude Code made shows up in Codex's next prompt, and plans, file changes, failures, and architecture notes are shared automatically, matched on-device against what you are asking about. Markdown in .atlas/knowledge/, plus the CLAUDE.md and AGENTS.md you already wrote, feed every agent in the project. So the existing files are not replaced. They become inputs.
The @ mention feature resolves files, folders, symbols, branches, commits, notes, papers, and past sessions locally before the prompt is sent. Local resolution matters here: it means the prompt payload is assembled on the machine rather than by a service that has to be reachable.
Getting it running: a dmg, and a source build for everything else
The documented install path is a .dmg from tryatlas.cc or the GitHub releases page. The README carries a note that macOS is the supported platform, and that Linux and Windows build from the same Tauri codebase but are untested. That is the state of platform support, stated plainly by the project itself. The README also contains a TODO comment about a Homebrew tap so the install becomes brew install atlas, which tells you that tap does not exist yet.
There is no install command sequence in the supplied material beyond the dmg and the build-from-source reference, so I cannot give you the exact cargo or npm invocation for a source build. What the material does establish is the runtime shape: a Tauri desktop app with a Rust core, a project-scoped .atlas/ directory holding sessions.db, knowledge/ for markdown notes, and the JSON and JSONL files for canvases and sessions.
The configuration surface described in the README is mostly filesystem-based rather than key-based. You put markdown in .atlas/knowledge/, you keep your CLAUDE.md and AGENTS.md where they already are, and the app reads them. The one setting with a real operational consequence is the gitignore entry for .atlas/. If the checkpoint database ends up committed, you are putting session transcripts into shared history, which is the opposite of what the project intends. The README states the directory is gitignored in the project, but your own repository is a separate matter.
Where Atlas is the wrong tool
The first limitation is platform. macOS is supported. Linux and Windows build from the same codebase but are untested, per the README. If your team is on Linux workstations, this is not a tool you can standardise on today, regardless of how well the checkpoint model fits your workflow.
The second is the dependency on ACP coverage. The README describes Claude Code and Codex as the most-used, most-tested path and says QA on the long tail of registry agents is ongoing. If your workflow depends on an agent that sits in that long tail, you are on unverified ground. The same applies to the native Atlas Agent, which runs on a hard fork of the Codex engine: a fork is a maintenance commitment, and the README does not describe how upstream changes are tracked.
The third is the local-first trade-off. Local by default is the right default for source code and prompts, but it means the checkpoint index is machine-local. A teammate cloning the repository gets the commits and none of the session links. The README points to signing in and creating an organisation for cross-team sync, but that is a different mode with a different data path, and the supplied material does not describe what is uploaded, how it is stored, or how it is removed.
Finally, the release tags are alpha and exp, with the most recent listed as alpha-0.3.1 from September 2026 and an experimental 0.3.1 the day before. That naming is a signal about interface stability, not a judgement about the code.
Against git notes, editor history, and agent-native memory files
The obvious comparison is git notes, which attach arbitrary metadata to a commit object without changing the commit hash. Notes travel with the repository when pushed, they survive rebases if you configure the refspec, and they need no daemon or database. If your requirement is strictly a prompt-to-commit link, git notes plus a script that writes the session ID at commit time gets you most of the way, with the metadata in git itself rather than in a gitignored SQLite file.
The difference in approach is what Atlas buys for the cost of the database. Notes are key-value blobs attached to a commit. Atlas stores the session, the tool calls, and the reasoning, then indexes them so you can query across sessions and chat with a checkpoint directly. The README describes selecting a checkpoint and asking it questions, with answers drawn from what actually happened in that session. That is retrieval over transcripts, not a metadata field, and it is the part git notes cannot do.
The second alternative is the agent-native memory file. Claude Code, Codex, and the others each keep their own history and their own memory format. That works fine while you use one agent. The README's argument is that it breaks the moment you switch mid-task, because the new agent cannot read the previous one's files. Atlas's answer is a shared layer that feeds CLAUDE.md, AGENTS.md, and .atlas/knowledge/ into whichever agent is running. If you never switch agents, that layer is overhead you are paying for nothing.
Maintenance cost, licence, and what to check before adopting
Atlas is MIT licensed. The practical implication is that you can read the source, fork it, and ship modifications, subject to the usual attribution terms. That matters more than usual here because the native agent runs on a fork of the Codex engine: if the fork drifts from upstream, the licence at least leaves the door open to maintaining your own build. This is not legal advice; read the LICENSE file for the actual terms.
The maintenance surface is threefold. You track Atlas releases, which are currently tagged alpha and exp. You track the ACP registry, since each registry agent pulls in its own official binary and a breaking change upstream lands in your workflow. And you track the Codex fork if you use the native agent. A team running Claude Code and Codex only has the smallest surface of the three.
The upgrade cost is mostly in the .atlas/ directory. Sessions are JSONL and notes are markdown, so the human-readable parts survive a version bump. The checkpoint index is SQLite, and the README does not describe a migration story for it, so a schema change between alpha releases is the thing to watch.
Four things to verify on your own repository before standardising. Confirm .atlas/ is ignored, since a committed sessions.db puts transcripts in shared history. Confirm the checkpoint link survives a rebase in your branching model, rather than trusting the README's claim on your workflow. Confirm local mode works with no account, because that is the mode the README describes in most detail. And confirm that the agent you actually use is on the tested ACP path rather than in the registry's long tail.
Editorial conclusion
Adopt Atlas if you already run Claude Code or Codex on macOS and want the prompt-to-commit link recorded without leaving the machine. Do not adopt it if you are on Linux or Windows, since the README states those build from the same Tauri codebase but are untested, or if you depend on a registry agent outside the well-tested ACP path. Before committing, verify that .atlas/ is in your .gitignore, that the checkpoint link survives a rebase in your own repo, and that local mode works with no account signed in.
Community notes