Atlas gained 1,077 GitHub stars in one day for keeping the part of an AI-written commit that Git never sees: the session that produced it. The MIT-licensed project links commits to prompts, tool calls, file changes, and the agent's account of its reasoning. That sudden attention is a community signal. It does not prove that teams have adopted Atlas. A diff can show what changed, but it cannot tell a reviewer which instructions shaped the change or which failed route the agent took first.
The repository had about 4,400 stars and 273 forks when checked on September 14. Its latest packaged version is alpha-0.3.1, released on September 6 for Apple silicon and Intel Macs. GitHub also showed 46 commits on main since that release. Atlas is moving fast enough that the source, the docs, and the installed application may describe slightly different moments. That matters for a tool whose pitch is preserving an exact account of how software came to be.
Git stores the result, Atlas stores the trail
A normal commit contains a snapshot, author data, parent references, and a message. Atlas adds a checkpoint in a project-level SQLite database. Its timeline documentation says the application watches repository history without installing hooks, changing Git configuration, or writing refs. When a commit appears, Atlas tries to associate it with the active agent session. Existing files match through paths the agent touched. New files must match content the agent produced. A purely human commit remains unlinked.
That matching rule is more careful than attaching the latest chat to the latest commit. Once a touched path has helped nominate a commit, Atlas stops reusing it for later commits. Merge commits do not create checkpoints. The repository documentation says ordinary amends and rebases are reconciled by patch ID, while a squash that makes authorship ambiguous leaves the session orphaned instead of guessing. A provenance system earns trust through these refusal cases because a confident false link would be worse than a missing one.
The resulting record is richer than a generated commit message. Atlas stores the prompt, messages, tool activity, affected files, and patches in .atlas/sessions.db, then lets a developer open a commit and return to the session behind it. The Git and diff guide keeps the final decision with the developer: review files, stage selected hunks, resolve conflicts, and confirm the commit. The agent history can explain a change, but it does not certify that the change is correct. Tests and human review still carry that burden.
Atlas leaves Git's object model and remote protocol alone. Its contribution is an audit trail that Git was never designed to hold. That trail could help when a reviewer finds a strange dependency choice months later, or when a second agent needs the constraint that shaped an earlier patch. The timeline can also retain sessions that never produced a commit, which keeps failed work visible instead of squeezing every experiment into repository history.
One memory, several agents
Atlas runs several coding systems behind one desktop interface. Claude Code and Codex connect as external processes over the Agent Client Protocol, while Atlas's native agent runs in process on a fork of the Codex engine. The project's architecture reference describes a shared connection interface based on advertised capabilities rather than agent names. When an unfamiliar ACP agent arrives with a different set of controls, the host can ask what it supports instead of filling the codebase with product-specific branches.
Before a prompt reaches an agent, Atlas can resolve explicit @ references and add project memory. Its memory guide says embeddings run on the device and match the new request against context left by earlier sessions. Project instructions such as CLAUDE.md and AGENTS.md join notes and saved decisions in the same retrieval path. A handoff can therefore carry a decision made in Claude Code into a later Codex session, even though those tools do not normally share their private histories.
Atlas is far larger than a thin agent wrapper. Atlas is a Tauri 2 application with a React 19 front end and a Rust back end. The architecture document lists 365 IPC commands across 70 modules, with Rust owning agent sessions, terminal state, Git operations, checkpoint storage, and local embeddings. The editor and terminal keep session context beside the code while different agents work on it.
Adopting Atlas means moving agent work into a new desktop shell even if a developer already uses a terminal or editor. Atlas's native agent is included, while external agents keep their own authentication and model choices. The supported-agents guide says Claude Code and Codex have the deepest integration, and that other ACP-compatible agents can be installed through the registry. The repository separately warns that quality checks across the long tail are ongoing. A six-name picker should not be read as six equally tested paths.
Our review of Atlas covers the setup reality, including the source-build footprint measured on an earlier alpha. Platform support is the immediate limit: the project README calls macOS supported and labels Linux and Windows builds untested, even though all three share the Tauri codebase. A team with mixed desktops cannot yet treat Atlas as common infrastructure without doing its own build and product testing.
The local record has a portability gap
On first use, Atlas adds .atlas/ to the project's .gitignore, according to the quickstart. The checkpoint database therefore does not travel in a normal clone. That is sensible for transcripts that may contain prompts or snippets from private files, and it keeps repository history clean. It also means the new provenance layer is easier to lose than the commit it explains. Delete the working directory or move to another machine without a separate transfer path, and Git can return while the agent trail does not.
Cloud organisations do not yet carry that record to another computer. Atlas's README invites users to create an organisation when they want team sync, yet the organisation guide says cloud organisations currently sync only the organisation record. It explicitly excludes code, sessions, chats, memory, and the timeline. The two documents conflict. A developer evaluating the shipped app should use the narrower public guide until a release states that session and timeline sync are available.
The word local applies to Atlas's own storage boundary. Atlas can keep its index and checkpoint record on the machine while Claude Code, Codex, or another selected agent sends prompts under its own provider policy. The memory documentation makes the on-device embedding claim. It cannot make a remote model local. Teams reviewing data flow need to separate Atlas's database, Atlas's optional services, and the provider used by each agent.
Atlas says it scrubs secrets before persisting a session, and its Rust architecture includes a dedicated redaction crate for credential patterns and high-entropy strings. That reduces the chance of copying an exposed token into the local audit trail. It is still a claim worth testing against each team's secret formats because redaction cannot promise perfect recall. The timeline guide frames this as protection for cases where an agent reads a file such as .env, which is exactly the kind of path a session recorder must handle conservatively.
Local storage does not mean zero traffic
Privacy-conscious users should also read past the phrase local by default. Official builds send usage analytics to PostHog unless the user turns off Share usage data. The project's telemetry catalogue says events can include tool counts, file extensions, lines changed, token use, model identifiers, and coarse location inferred from the request IP. It says prompts, responses, code, paths, diffs, and tool arguments are excluded. Source builds without a PostHog key are inert, which gives auditors a cleaner starting point.
The same policy says account identification can merge earlier anonymous device events into an account when usage-data linking is enabled. Turning analytics off stops new queued events immediately, though update checks have a separate control and submitted feedback follows the user's explicit send action. Local sessions and zero network activity are separate promises, each with its own switch. The telemetry file is explicit enough for a team to write tests around each promise.
The proof is a shared checkpoint
Atlas's 1,077-star day is an attention signal around a gap in Git history. The next evidence should be a release where two machines recover the same checkpoint, with controls for what crosses the network and documented behavior after rebase or squash. Until then, alpha-0.3.1 is best evaluated as a single-machine alpha. The decisive test is mundane: clone the repository on a teammate's computer and ask why an old commit exists. Git will bring back the code. Atlas's current organisation guide says the session behind it will not follow.