Atlas
Source control for coding agents: every commit linked back to the session, prompts, and tool calls that produced it.
- Source repo
- pacifio/atlas
- Stars
- ★ 9.6k
- Last updated
- 11d ago
- License
- Apache-2.0
- Primary language
- Rust
- FA score
- 50/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- You run Claude Code and Codex against the same repository and want them to share one record of plans, decisions, and file changes instead of re-explaining the context on every switch.
- Not a fit if
- Developers who want a terminal-only workflow and no desktop app
- Teams that need a supported, tested Linux build
- Anyone unwilling to keep a local .atlas/sessions.db session record on disk
- Source review
- 50/100 · Major gaps
What does this agent do, and when should you use it?
Atlas is a Tauri desktop application for macOS and Windows that positions itself as source control for coding agents. It runs Claude Code and Codex as external subprocesses over ACP (Agent Client Protocol) and ships its own in-process Atlas Agent, and it can spawn other agents from the ACP registry such as Cursor, OpenCode, and Kilo Code by pulling their official binaries. Sessions run against the same codebase in parallel and are recorded to a gitignored .atlas/sessions.db inside the project. When you commit, the commit is linked back to the session that produced it as a checkpoint, and those links survive amend and rebase. Around each turn Atlas assembles shared agent memory, locally resolved @ mentions, on-device semantic matches, and a first-message session handoff, so agents can see each other's plans, decisions, and file changes. The app also bundles an editor, a Git commit graph, a block terminal, a Markdown knowledge base, arXiv and Semantic Scholar research, a browser tab, and an activity log, all local by default.
Atlas drives agents per session. Claude Code and Codex run as external subprocesses over ACP; Atlas Agent runs in-process on its own engine. Before a message reaches an agent, Rust resolves @ mentions locally (files and folders become a path the agent reads on demand; notes, skills, papers, and past sessions are inlined), pulls the active plan, decisions, file changes, failures, and architecture notes out of shared agent memory, and embeds your message on-device to match it against the project's memory index (local embeddings plus HNSW search). The first message in a project also carries a curated fact pack and the tail of your previous session, including one from a different agent. Prompts, messages, tool calls, touched files, and applied patches are written to .atlas/sessions.db with secrets scrubbed before anything touches disk. Commits are observed rather than intercepted, so a commit made from a terminal, another editor, or while Atlas is closed still finds its session and becomes a checkpoint; amend and rebase re-point links by patch-id reconciliation, and an ambiguous squash orphans instead of guessing. Existing Claude Code history can be imported and backfilled. The UI side provides a CodeMirror editing surface, a real commit graph with lane assignment, a block terminal where each command carries its output, exit code, and duration, a Markdown knowledge base under .atlas/knowledge/ with backlinks, a link graph, and HTML or standalone-server export, arXiv and Semantic Scholar search, a native WebKit browser tab with reader mode, JSON-persisted Spaces boards, and split view up to three columns.
- You run Claude Code and Codex against the same repository and want them to share one record of plans, decisions, and file changes instead of re-explaining the context on every switch.
- Months later you need to answer why a line of code looks the way it does, and you want to select the checkpoint and ask that session directly instead of reading a model-written commit message.
- Your team already pays for Claude Code or Codex subscriptions and wants to route them through Atlas for richer context without changing how anyone works.
- You need agentic coding to stay on the machine, with notes and sessions local and secrets redacted before anything is persisted.
- You want the CLAUDE.md, AGENTS.md, and scattered Markdown notes you already wrote folded into one index that every agent in the project reads.
- You want a Mission control dashboard showing agent usage over time, consumption breakdown, timelines, and a filterable log table per project.
How do you install or deploy this agent?
Most users install a build rather than compile: grab a .dmg for macOS (Apple Silicon or Intel) or an .msi for Windows from https://www.tryatlas.cc/ or the GitHub releases page and run the installer. The supported platforms are macOS 13+ and Windows 10+ (x64); Linux builds from the same Tauri codebase but is documented as untested. Building from source requires Bun and Rust (stable, via rustup), plus Xcode Command Line Tools on macOS or MSVC build tools (Visual Studio Build Tools with the C++ workload) on Windows.
How do you use this agent?
Work per project: open a local Git repository, then pick the agent for each session (Claude Code, Codex, Atlas's own agent, or anything from the ACP registry). Sessions are independent of tabs, so switching tabs never drops a run in flight. To use the Claude Code agent, install the claude CLI and put it on your PATH first; the native Atlas agent needs no external CLI. Reference files, folders, symbols, branches, commits, notes, skills, papers, and past sessions with @ in a prompt; resolution happens locally in Rust, with files and folders resolving to a path the agent reads on demand and notes, skills, papers, and sessions inlined. After committing, select a checkpoint and chat with it to get the context back. Production builds use the following commands; local mode needs no account and no network, while signing in and creating an organization enables cross-device and teammate sync.
What are this agent's strengths and limitations?
- Checkpoints link a commit back to the session that produced it, and commits are observed rather than intercepted, so a commit made in a terminal, another editor, or while Atlas was closed still finds its session; links re-point through amend and rebase by patch-id reconciliation.
- Shared cross-agent memory: a decision Claude Code made shows up in Codex's next prompt and vice versa, switching agents mid-task does not mean starting over, and existing Claude Code history can be imported as backfill.
- No format lock-in: notes are Markdown, canvases are JSON, sessions are JSONL, and the editor is a file on disk, so you can close Atlas and continue in vim. The only exception is the queried checkpoint record, which is SQLite in the project's gitignored .atlas/.
- Local by default: secrets are scrubbed before persistence rather than before upload, session capture stays in .atlas/sessions.db, and embeddings run on-device.
- One app covers editor, lane-assigned Git commit graph, block terminal, knowledge base with backlinks and export, arXiv/Semantic Scholar research, a WebKit browser, and up to three resizable columns.
- Linux builds from the same Tauri codebase but is explicitly documented as untested; supported platforms are macOS 13+ and Windows 10+ (x64) only.
- Source builds are heavy: Bun, Rust stable, Xcode Command Line Tools or MSVC build tools, plus GTK 3, WebKit2GTK 4.1, and GLib headers on Linux, and the first Rust compile takes a few minutes.
- QA on the long tail of ACP registry agents is documented as ongoing, so agents beyond Claude Code and Codex are a less-verified path.
- Anonymous usage analytics are on by default with coarse metadata only, and opting out requires following TELEMETRY.md, which data-sensitive teams must handle first.
- The checkpoint record lives in the project's gitignored .atlas/ directory, so it is local state that teammates do not share automatically until you sign in and create an organization.
- Contribution workflow constraint: feature work targets the current version branch, not main, and merging a finished version branch into main is the release.
How does this agent compare with similar options?
Atlas frames itself against editors designed before agents, naming three consequences: agents start from zero every session, switching agents loses the thread, and context lives in ten places (the knowledge base, CLAUDE.md, AGENTS.md, and each agent's own memory files). It also separates itself from running a single agent: Claude Code cannot read Codex's history and Codex cannot read Claude Code's, while Atlas matches both against one shared memory index. It does not replace Claude Code or Codex; it runs them, plus ACP registry agents such as Cursor, OpenCode, and Kilo Code, underneath itself.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Atlas This agent | 50 · Major gaps | Desktop appFree + model costs | ★ 9.6k | 11d ago | Rust | Codex · Claude Code |
| MonoCode | 56 · Major gaps | Desktop appFree | ★ 3.1k | today | TypeScript | Codex · Claude Code |
| PRO-LONG | 57 · Major gaps | CLIFree | ★ 458 | 2mo ago | Python | Codex · Claude Code |
| Keep the Why | 75 · Good | Agent plugin / skillFree | ★ 231 | today | Python | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows Atlas runs agents locally, scrubs secrets before writing to .atlas/sessions.db, and discloses anonymous telemetry on by default with an opt-out (TELEMETRY.md), giving decent data-flow transparency. However, no least-privilege design is shown (agents run as subprocesses/in-process with no sandbox or permission boundary described), no user confirmation mechanism appears (commits and automatic external agent binary pulls have no confirmation step), and rollback is only mentioned as checkpoint links surviving rebase/amend, not how to undo agent changes. Dependency security has many exact pins and comments, but includes git dependencies (nucleo, runfiles) and a '*' version (openssl-sys) with no vulnerability audit evidence, so points are deducted.
README and Cargo.toml are consistent about workspace structure, vendored engine, and CI planning logic, so self-consistency is fair. Dependency availability is risky: nucleo and runfiles are pinned to git revs, openssl-sys is '*', and the vendored engine depends on an upstream repo, so offline or upstream changes can break builds. Failure messages are weak: CI comments note that sandbox failures are translated into misleading messages (bwrap missing reported as command never ran), so points are deducted.
README clearly lists macOS 13+/Windows 10+ support, untested Linux, and multi-agent scenarios (Claude Code, Codex, Atlas Agent, ACP registry), so audience and scenarios are well covered. Capability boundaries are stated (local-first, sync requires sign-in, long-tail registry agent QA ongoing). Trigger precision is coarse: @ mentions, memory injection, and semantic matching lack precise trigger rules or configuration. Environment fit provides Linux dependencies and build commands, but Linux is explicitly untested, so points are deducted.
Information architecture is clear with complete README sections, and install notes include Bun/Rust/system dependencies and build commands. Naming stability is weak: heavy use of vendor/atlas-engine renaming and ADR-0011 rename noted in Cargo.toml, so historical naming changes may affect users. Examples and FAQ are limited to a few code blocks with no FAQ. Known limitations are stated (untested Linux, long-tail agent QA ongoing). License is full Apache-2.0 with LICENSE file present, earning full marks. Versioning/changelog has a version in package.json but no CHANGELOG file. Maintenance responsibility is unclear with no named maintainer or support channel beyond a Discord link, so points are deducted.
Output usability is decent: checkpoints, session records, and knowledge base outputs are described and queryable, but no output format examples or export samples are given. Marginal value is differentiated by multi-agent shared memory and checkpoint linking, but requires runtime verification. Cost-benefit is high: building needs Bun, Rust, many system dependencies, long compile times, and a large vendored engine, so points are deducted.
claim_traceability: many capability claims (secret scrubbing, semantic matching, checkpoint linking) lack traceable code references or test evidence, with only a few doc links. cross_source_corroboration: Cargo.toml and CI config partially corroborate workspace and vendored engine structure, but README feature claims lack multi-source verification. fact_inference_separation: README mixes product vision with factual statements without clearly separating verified facts from inference, so points are deducted.
- No least-privilege or sandbox design is described; agents run as subprocesses/in-process and may inherit the user's filesystem permissions.
- Automatic ACP registry agent binary pulls have no user confirmation step, posing supply-chain risk.
- Dependencies include git-rev-pinned nucleo and runfiles plus a '*' version of openssl-sys, raising build reproducibility and security concerns.
- Linux is explicitly untested, and CI comments note sandbox failure messages can be misleading (missing bwrap reported as command never ran).
- Many README capability claims lack traceable code or test evidence and require runtime verification.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
alpha-0.3.4 Atlas Teams Early
-
alpha-0.3.3 Atlas windows patches