Atlas: source control for coding agents, reviewed for the macOS Tauri app

The gap Atlas is built to close: commits with no reasoning attached

A commit message written by a model summarises a diff. It does not record the prompt that produced the change, the tool calls the agent made, or the approach it tried and abandoned first. The README states the problem directly: agents write a large share of the code and keep none of the reasoning behind it, and what survives is a model-written summary of a diff. Months later that summary is the only record of why the code looks the way it does.

Atlas is aimed at developers who already run more than one coding agent against the same repository. The README names three failures it targets: agents start from zero each session, switching agents loses the thread because Claude Code cannot read Codex's history and the reverse, and context is scattered across a knowledge base, `CLAUDE.md`, `AGENTS.md` and each agent's own memory files with nothing reading all of them at once. If you run a single agent in a single terminal and never revisit old changes, the product has no problem to solve for you.

Checkpoints, sessions.db and how a commit gets linked to a session

The mechanism is a checkpoint. Atlas records every agent session locally in `.atlas/sessions.db`, and the README states secrets are 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. The README claims those links survive rebases and amends.

The storage split is deliberate. Notes are markdown, canvases are JSON, sessions are JSONL, and the editor is a file on disk, so the README says you can close Atlas and pick up in vim. The one exception is the checkpoint record itself, which agent session produced which commit, stored as SQLite in the project's gitignored `.atlas/` because, in the project's words, it is queried rather than read. That is a defensible choice and also the lock-in point: the record you would most want to grep is the one kept in a binary format inside a gitignored directory.

Agent execution has two paths. Claude Code and Codex run as external subprocesses over ACP, which the README calls the most-used, most-tested path. Atlas Agent, the native agent, runs in-process on a hard fork of the Codex engine, documented in `CONTEXT.md` and ADR-0004. Any other agent in the ACP registry, including Cursor, OpenCode and Kilo Code, can be spawned, with Atlas pulling in each one's official binary automatically. The README notes that QA on the long tail of registry agents is ongoing, which is worth reading as a warning about the less common ones.

Installing Atlas on macOS and getting a first checkpoint

The supported install path is a prebuilt macOS app. The README says to grab the latest `.dmg` from tryatlas.cc or the releases page. There is no Homebrew formula: the README carries a `#todo` comment about a tap so the install would become `brew install atlas`. If you are on Linux or Windows, the README states those build from the same Tauri codebase but are untested.

Building from source is a Tauri project with a Bun frontend and a Rust workspace. The `package.json` scripts give the entry points. The dev script runs Vite alone, and the app script wraps the Tauri dev command so telemetry environment values are exported before the Rust compile:

bun install
bun run dev:app

The wrapper matters because the PostHog keys are baked into the binary at build time via `option_env!`. Copy the environment template and fill it in if you want telemetry, or leave the key blank to build Atlas with telemetry permanently inert:

cp .env.example .env

The template defines `ATLAS_POSTHOG_KEY` and `ATLAS_POSTHOG_HOST`, the latter defaulting to `https://us.i.posthog.com`. The file comments state the project key is a write-only ingest key safe to ship in a client app, and that the values are also honored at runtime for `cargo run` and source development without the wrapper.

For a packaged build, `bun run build:app:dmg:arm` produces an Apple Silicon disk image. For a first real use, open a project, run one agent session, make a change and commit it. The README says local mode works fully offline with no account, so you can confirm the checkpoint appears without signing in. Then select the checkpoint and chat with it: the README states it answers from what actually happened in that session rather than from the raw transcript.

Where Atlas falls short: platform support, alpha status and the SQLite exception

The platform constraint is the largest one and the README does not soften it. macOS is the supported platform. Linux and Windows build from the same Tauri codebase but are untested, which is not the same as unsupported and not the same as working. If your team is mixed-platform, the checkpoint record lives in a per-project `.atlas/` directory that a Windows colleague cannot generate with the shipped app.

Release cadence is early. The recent releases are `alpha-0.3.1` (Atlas comms alpha) on 2026-09-06, `exp-0.3.1` on 2026-09-05, and `alpha-0.3.0` (Atlas ACP + Timeline) on 2026-08-25. The `exp-` prefix and the alpha naming suggest the project is still experimenting with its own release channels. The last push to the repository was on 2026-09-10, so development is current, but current development on an alpha is not the same as a stable surface you can build a workflow on.

The other limitation is the storage asymmetry. Everything the README lists as portable is portable: markdown notes, JSON canvases, JSONL sessions, a file-based editor. The checkpoint index is not, because it is SQLite in a gitignored directory. If your reason for adopting Atlas is auditability months later, the audit trail lives in a file format the README justifies on query grounds rather than readability grounds. That is a trade-off, not a defect, but it is the one place where the project's own "nothing is locked in" commitment has an exception the README admits to.

How Atlas differs from plain git and from agent-native memory files

Plain git records what changed. It has no concept of which agent session produced a change, and its commit messages are written after the fact by whoever or whatever runs the commit. Atlas adds a side record keyed to the commit that points back at the session, and the README says that link survives rebases and amends. Nothing in git does that, and no git hook can reconstruct it after the fact because the session transcript is gone once the terminal scrolls.

The nearer alternative is the per-agent memory file: `CLAUDE.md`, `AGENTS.md`, and whatever memory store each agent keeps. Atlas does not replace those. The README states the markdown you already wrote feeds every agent in the project, alongside markdown in `.atlas/knowledge/`. The difference in approach is aggregation. A memory file is written by you for one agent and read by that agent. Atlas's shared memory is matched on-device against what you are asking about, so a decision Claude Code made can surface in Codex's next prompt. Whether that matching is good enough in practice is not something the README quantifies, and the README does not document how conflicts between two agents' notes are resolved.

Licence, telemetry and the cost of keeping Atlas current

Atlas is MIT licensed. That is permissive: you can fork it, ship a modified build, and use it commercially without a copyleft obligation on your own code. The practical constraint is not the licence text but the vendored engine. The root `Cargo.toml` describes a hard fork of the Codex engine landing in the same workspace as the app, and the workspace comment explains that it exists so the vendored engine shares one dependency graph. A fork of an upstream engine is a maintenance surface: upstream changes have to be pulled in by hand, and the workspace comment records a real instance of that pain, a dependency pin collision between `agent-client-protocol` 1.3 and 2.0 that no single cargo resolution could hold.

Telemetry is opt-in at build time. The `.env.example` file states that leaving `ATLAS_POSTHOG_KEY` blank builds Atlas with telemetry permanently inert, and the repository carries a `TELEMETRY.md` alongside it. Since the key is baked in via `option_env!`, a binary you download was built with whatever key the maintainer set, not with yours. If telemetry policy matters to your organisation, build from source with the key blank rather than relying on a runtime toggle.

Upgrade cost is the usual alpha cost. The release names suggest overlapping channels, and the last push was on 2026-09-10. The repository carries `bump.sh` and `debump.sh` at the top level, which implies version bumping is scripted rather than manual, but the README does not document a migration path for `.atlas/sessions.db` between versions. Back that file up before upgrading if you care about old checkpoints.

Editorial conclusion

Adopt Atlas if you already run Claude Code or Codex on macOS and keep losing the reasoning behind agent-written commits; the checkpoint model is the part worth evaluating. Do not adopt it if you need Linux or Windows today, since the README states those build from the same Tauri codebase but are untested, or if you want a stable release rather than an alpha. Verify two things first: that `.atlas/sessions.db` records your sessions with secrets scrubbed as documented, and that a commit made while Atlas is closed still links back to its session after a rebase.

Frequently asked questions

Official sources

1. License: MIT
2. pacifio/atlas on GitHub
3. Project website
4. README
5. Releases