Zeron: a local-first control plane for Claude Code, Codex and Cursor sessions

What Zeron solves for people running several coding agents

A coding agent is usually tied to the machine where you started it. Close the laptop and the session stops being reachable, even though the process may still be alive. Zeron's answer is an engine that runs on every device and stores that device's sessions locally. The README states that a new installation starts in local-only mode, with no account and no network connection required. The project describes itself as a native control plane for Claude Code, Codex, Cursor, Devin, Grok, Hermes and Pi, so the target user is someone who already juggles more than one agent and more than one machine. The desktop app is the visible surface: the README screenshot shows a Claude Code session with a live branch diff sidebar. Rust is the implementation language, and the workspace in Cargo.toml lists crates for the engine, RPC, sync, preview, document handling, syntax, theme and UI, plus an apps/zeron binary. That layout matters, because it tells you the local data plane and the optional sync plane are separate crates rather than one monolith.

How the local engine, sync and the SessionRoom protocol fit together

Each device runs its own engine and owns its own session data. Local-only mode is the default after install, and the README is explicit that signing in does not upload, move or import existing local sessions: they stay under the local profile and reappear when you return to local-only mode. Sync is a second profile, not a migration. The workspace dependencies show how the replicated part is built: loro 1.13 for CRDT state and loro-protocol 0.3, described in Cargo.toml as the official Rust twin of the npm loro-protocol package that the TypeScript edge speaks, with byte-identical frames cross-checked by js_snapshots tests. So the sync path is a CRDT room protocol shared between a Rust side and a TypeScript edge, which is why the repository has a top-level edge/ directory next to crates/ and apps/. The UI layer is a fork of gpui kept under zeronsh/zui; the Cargo.toml comment says it removes GPL tracing crates and composites deferred GPUI content above native macOS views. That is an unusual amount of vendoring for a young project, and it is the kind of choice that makes upstream bumps expensive later.

Installing Zeron on Linux and checking the engine

The README gives a single install path for Linux: a shell script fetched with curl and piped to sh. According to the README, the installer starts the daemon immediately and keeps it running across reboots, and no sign-in or sync configuration is required. Run the status command afterwards; it reports local or synced mode together with engine status.

curl -fsSL https://zeron.sh/install.sh | sh
zeron status

The desktop sidebar browser needs an additional Linux browser runtime, documented in docs/reference/linux-browser.md. Day-to-day commands are short.

zeron update
zeron daemon start|stop|restart|status

If you want sync, the README is specific about ordering: authentication changes the profile selected by the next engine start, so the daemon must be stopped before you change it, and zeron login and zeron logout refuse to modify credentials while an engine owns the data directory.

zeron daemon stop
zeron login
zeron daemon start

On macOS the README does not offer the same script. It says to use the desktop release, or to build zeron from source and run zeron daemon install to install the launchd service.

The sync trust model is the part to read twice

Zeron's documentation does not soften this: devices signed in to the same synced account are trusted with remote workspace access. A device controlling a workspace on another device can list, read and write its files. Enabling the Show ignored files option also makes gitignored files such as .env available remotely. The one hard exclusion stated in the README is .git, which is always excluded. So the security boundary is the account, not the individual workspace, and there is no per-workspace scoping described. The README's own guidance is to sign in only devices you trust with the full contents of your workspaces. If your agents touch production credentials in .env files, that sentence is the whole risk assessment. There is a second, smaller failure mode: because credentials are refused while an engine owns the data directory, a login attempt during a running daemon will not silently switch profiles, it will fail. That is the right behaviour, but it means profile changes are a stop-start operation rather than a live toggle.

Where Zeron is the wrong tool

If you work on macOS and do not want to compile Rust, Zeron is not a one-command install. The README points to a desktop release or to building from source with zeron daemon install for the launchd service, and it does not document rollback for that service or for the Linux daemon. The release cadence is also worth noting: v0.2.58, v0.2.59 and v0.2.60 all landed between 2026-09-09 and 2026-09-10, and the workspace version in Cargo.toml is 0.2.65, ahead of the newest release in the list. That pace means the CLI surface and the profile boundary are still moving, and a team standardising on exact command behaviour should pin a release rather than track zeron update. Finally, Zeron is a control plane, not an agent. It does not replace Claude Code, Codex or Cursor, and it does not make an agent's output better. If your sessions never leave one laptop and one terminal, the engine, the daemon and the profile boundary are overhead with no payoff.

How Zeron differs from tmux plus an agent CLI

The obvious alternative is tmux on an always-on machine, with SSH from wherever you are. That approach keeps a session alive and lets you attach from a second terminal, and it requires nothing beyond SSH keys. The difference in approach is where state lives. With tmux, the session is a process on one host and the remote client is a terminal multiplexer; there is no replicated state, so two people or two devices cannot both drive the same session, and the file tree you see is whatever the remote shell shows you. Zeron instead runs an engine per device and replicates session state through the loro CRDT rooms, which is what allows the README's scenario of starting an agent on one synced device and following or driving it from another, and what allows the controlling device to list, read and write files in the remote workspace. The trade is that tmux grants access through an SSH account you already control, while Zeron grants it through a synced account whose devices are mutually trusted. Pick tmux when the only requirement is persistence; pick Zeron when the requirement is a shared, drivable session with a file view attached.

Licence and the cost of upgrading

Zeron is MIT licensed, and the workspace manifest sets license = "MIT" with publish = false, so the crates are not published to crates.io under that setting. The repository also carries a THIRD_PARTY_NOTICES.md file, which is the place to look before redistributing a build, because the vendored gpui fork and the CRDT dependencies bring their own terms. This is not legal advice; if you ship Zeron inside a product, read LICENSE and THIRD_PARTY_NOTICES.md yourself. On upgrade cost, the practical friction is the vendored UI layer. The Cargo.toml comment describes the gpui fork as extracted from wingleeio/zed at a specific revision, with preserved fork history and an instruction to rebase when bumping the upstream rev, and it lists behaviour added on top such as bounded blur passes and horizontal per-pixel edge fades. Every upstream gpui change has to be reconciled against those additions. The sync crates add a second axis: loro-protocol frames must stay byte-identical to the TypeScript edge, so a protocol bump is a two-language change. zeron update handles the binary; it does not reduce that maintenance surface for anyone building from source.

Editorial conclusion

Adopt Zeron if you already run Claude Code, Codex or Cursor on a Linux box and want the same session reachable from a second device without moving your files. Skip it if you work on macOS and do not want to build from source, or if you cannot accept that any device signed into the same synced account can read and write the files of a workspace it controls, including gitignored files once Show ignored files is enabled. Before committing, run zeron status to confirm the engine reports local mode, then verify on a throwaway repository what a second signed-in device can actually list and read.

Frequently asked questions

Official sources

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