Model or dataset
pacifio/atlas avatar
pacifio/atlas

Atlas: every commit linked back to the session that wrote it

Source control for agents. Use multiple coding agents, track their changes and query them in one place

9,423 stars369 forksRustApache-2.0

At a glance

What is it?
Atlas is a Tauri desktop app that treats agent runs as versioned history: commits link back to the sessions behind them, and one memory index feeds Claude Code, Codex, or any ACP registry agent. The costs are a SQLite checkpoint store you cannot version, a forked native agent, and a Linux build marked untested.
Who is it for?
Atlas fits a team running more than one coding agent against the same repository and losing track of the reasoning behind a diff, because the checkpoint link and the shared memory index solve that in one local folder. It does not fit a single-agent, single-file workflow, where the SQLite checkpoint store and the in-process agent engine add weight without payoff.
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 1 day ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.

From daily snapshots

Star history

  • pacifio/atlas9,423 ★ · +6,127
Star history
Repository2026-09-112026-11-14
pacifio/atlas3.3k9.4k

6,127 Stars in the last 64 days, measured from the daily GitHub snapshot. Compare with other projects

Editorial analysis

A commit carries the session that wrote it, and the link survives a rebase

Atlas treats a commit as incomplete without the session behind it, and it fills that gap from local records rather than from the commit message. Commit from any tool, even with Atlas closed, and the commit is linked back to the session that produced it, with prompts, tool calls, and file changes kept together. The link survives rebases and amends, which is the part that counts: a checkpoint attached to a raw commit hash would be worthless the first time history moved.

Sessions are recorded in the project with secrets scrubbed before anything touches disk. The docs name .atlas/sessions.db as the local store, while the format commitments list sessions as JSONL.

You do not have to read a raw transcript to get context back. Selecting a checkpoint lets you chat with it, and it answers from what actually happened in that session rather than from a summary written after the fact.

@ mentions resolve in Rust before the prompt leaves the machine

Context assembly happens before an agent sees your message, and the send path is identical whichever agent you picked. Claude Code and Codex run as external subprocesses over ACP. Atlas Agent, the native one, runs in-process on its own engine. Anything from the ACP registry is spawned with its official binary pulled in automatically. All of them pass through the same send path, so the injection rules do not fork per agent.

Five kinds of material get injected. @ mentions are resolved locally in Rust, so notes, skills, papers, and past sessions are inlined while files and folders resolve to a path. Shared agent memory carries the active plan, decisions, file changes, failures, and architecture notes written by any agent. Your message is embedded on-device and matched against the project memory index for semantic matches. A session handoff, a curated fact pack plus the tail of your last session in this project including one from a different agent, goes in on the first message. Knowledge notes, CLAUDE.md, AGENTS.md, Claude Code's memory files, and Codex's history are folded into one index.

Embedding on-device is what lets that semantic layer work without a hosted index.

Notes are markdown and the editor is a file, but checkpoints are SQLite

Atlas states two commitments and documents one exception. The open-format side is broad: notes are markdown, canvases are JSON, sessions are JSONL, and the editor is a file on disk, so closing Atlas and continuing in vim loses nothing. The exception is the checkpoint record, the mapping from agent session to commit, which is SQLite in the project's gitignored .atlas/ directory because it is queried rather than read.

That split has a consequence worth planning around. Notes are safe to version and review, while the index tying sessions to commits is neither in git nor mergeable. The gitignored side cuts the other way too: a fresh clone on another machine has no checkpoint links until sessions are recorded there.

Local mode works fully offline with no account. Code, notes, and sessions stay on the machine, and signing in to create an organisation is what adds sync across a team.

Two installer files, no package manager, and a Linux build marked untested

There is no install command in the documentation, and the download path is a file: a .dmg for macOS on either Apple Silicon or Intel, and an .msi for Windows. macOS 13+ and Windows 10+ on x64 are the supported platforms. The README also carries a commented-out line reserving a Homebrew tap so the install would become brew install atlas, which tells you the tap does not exist yet. Plan for a manual install or a source build.

Linux has a build from the same Tauri codebase and is labelled untested. The source build is where the platform split becomes visible, because each target has its own invocation:

sh
bash scripts/build-dmg.sh arm
bash scripts/build-dmg.sh intel
node scripts/with-posthog-env.mjs tauri build --target x86_64-pc-windows-msvc --bundles msi
node scripts/with-posthog-env.mjs tauri build --config src-tauri/tauri.linux.conf.json

Linux needs its own Tauri config file, src-tauri/tauri.linux.conf.json, rather than a flag. The wrapper in front of the Windows and Linux builds is not decoration: it loads the environment before the Rust compile.

Two exact ACP pins could not share one cargo graph

The root Cargo.toml opens with a scar. The old ACP stack pinned agent-client-protocol 1.3, whose schema crate was pinned exactly as =1.4.0, while the ported stack pinned 2.0 at =1.5.0, and no single cargo resolution can hold two exact pins of the same crate. That collision is why the repository had no workspace section at all until the old stack was removed.

toml
[workspace]
resolver = "2"

The workspace now exists for a second reason, to land the vendored engine in the same dependency graph as the app instead of a parallel one. Every remaining ACP consumer sits on =2.0.0, which is why the conflict disappeared without a version negotiation.

The comment also records a trap for anyone restructuring the manifest. Cargo honours patch tables and profiles only in the manifest it was invoked on, and in a workspace that is always the root. tests/cargo-workspace.test.ts exists to enforce the invariants that produce no compile error: patches and profiles appearing nowhere else, and a dev opt-level restated for every member.

Telemetry keys are baked into the binary before the Rust compile

Telemetry is wired through the build rather than a settings screen, and the environment template makes that explicit. scripts/with-posthog-env.mjs loads .env and exports the values so they are baked into the binary at build time through option_env! in src-tauri/src/telemetry/mod.rs. The same keys are honoured at runtime through dotenvy for cargo run and source development without the wrapper.

sh
ATLAS_POSTHOG_KEY=
ATLAS_POSTHOG_HOST=https://us.i.posthog.com

The stated rationale is that a PostHog project key is a write-only ingest key, safe to ship in a client app. Leave the key blank and Atlas builds with telemetry permanently inert, which is the switch to pull if you distribute a build yourself. The ingest host defaults to PostHog US cloud when blank, with the EU endpoint listed as the alternative in the template. .env is gitignored while this template is committed, so the key stays out of the repository as long as you copy the file rather than editing the template.

The native agent is a hard fork, and the registry tail is untested

Atlas runs its own agent in-process on its own engine, and that engine is described as a hard fork of an Apache-2.0 upstream, with the reasoning in CONTEXT.md and two architecture decisions, ADR-0003 and ADR-0011. Upstream changes do not arrive on their own, so the fork absorbs them. A vendor/ directory sits at the top of the repository, which is where a forked engine would live in-tree.

The wider registry is handled differently and more loosely. Atlas can spawn any agent in the ACP registry, with Cursor, OpenCode, and Kilo Code named, pulling in each one's official binary automatically. The docs flag that QA on the long tail of registry agents is ongoing, so an agent pulled from the registry carries a different risk profile from Claude Code or Codex, which run over the path described as the most used and most tested.

Version numbering needs the same caution. The application manifest sits at 0.4.1, and the published releases are alpha-0.4.1-org-agent on 2026-11-03, alpha-0.4.1 (Atlas Teams Beta) on 2026-10-19 and alpha-0.3.4 (Atlas Teams Early) on 2026-09-27, all still tagged alpha. The last push was on 2026-11-02.

Editorial conclusion

Atlas fits a team running more than one coding agent against the same repository and losing track of the reasoning behind a diff, because the checkpoint link and the shared memory index solve that in one local folder. It does not fit a single-agent, single-file workflow, where the SQLite checkpoint store and the in-process agent engine add weight without payoff. Before adopting, confirm two things: that the agents you actually use sit on the tested ACP path rather than the long tail, and that your oldest machines clear macOS 13 or Windows 10 on x64, since Linux builds are marked untested.

Frequently asked questions

How do I install Atlas?

There is no package manager entry, so the documented path is a file download from tryatlas.cc or the GitHub releases page: a .dmg for macOS on Apple Silicon or Intel, and an .msi for Windows. The supported platforms are macOS 13+ and Windows 10+ on x64.

Can Atlas run on Linux?

A Linux build exists from the same Tauri codebase, but the documentation marks it untested. macOS and Windows are the platforms described as supported, and the Linux build uses its own Tauri config, src-tauri/tauri.linux.conf.json.

Do I need an Atlas account to use it?

No. Local mode works fully offline with no account, and code, notes, and sessions stay on the machine. Signing in and creating an organisation is what adds sync across a team.

Where does Atlas store session data?

Sessions are recorded in the project with secrets scrubbed before anything touches disk, and .atlas/sessions.db is named as the local store. The checkpoint record that maps a session to a commit is SQLite inside the gitignored .atlas/ directory, because it is queried rather than read.

Does Atlas send telemetry?

Telemetry keys are read from .env by scripts/with-posthog-env.mjs and baked into the binary at build time through option_env!, and they are also honoured at runtime for cargo run. Leaving ATLAS_POSTHOG_KEY blank builds Atlas with telemetry permanently inert.

Official sources

  1. License: MIT
  2. pacifio/atlas on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/pacifio-atlas.svg)](https://hysenlabs.com/projects/pacifio-atlas)

Star history chart for your README

markdown
[![Star history](https://hysenlabs.com/chart/pacifio-atlas.svg)](https://hysenlabs.com/projects/pacifio-atlas)

Was this useful?