In-memory worktrees for parallel AI agents.
A next-generation version control system built around a snapshot-and-tag model (Jujutsu-inspired), with in-memory virtual worktrees, native committed secrets, recipient-encrypted paths, and private branches — plus a native desktop browser for refs, snapshot DAGs, provenance, public trees, and diffs. The path- and branch-level permission thesis is built end to end.
A checkout assumes one developer, one directory, one disk. Agent fleets break all three: they want dozens of concurrent worktrees, forked in milliseconds, and gone without a trace when the run ends. Disk-bound worktrees leak state and don't scale to that.
The demo
Fork parallel worktrees off one snapshot, run against each, tear down — then prove nothing touched disk with an independent before/after filesystem diff.
# fork 4 parallel in-RAM worktrees, run and check out against each
$ cargo run --bin sc -- demo --agents 4
# force the bounded budget: LRU eviction + spill, auto-cleaned
$ cargo run --bin sc -- demo --agents 6 --budget-mb 4 --spill
# independent zero-residue proof (snapshots the filesystem before/after)
$ bash demo/run_demo.sh
# agent workspaces: fork N workspaces, run a command in each, harvest results
$ sc work --agents 4 -- cargo test
# seal an agent-session transcript and attach it to a commit, signed
$ sc transcript attach HEAD session.json --sign
# stage an embargoed fix on a private branch — content, paths, messages
# all sealed to the recipient set — then make it public in one atomic move
$ sc branch hotfix --private --to alice
$ sc branch grant hotfix --to bob
$ sc branch publish hotfix
# interoperate with Git: import a repo's HEAD, export history back,
# or use a Git repo (local or GitHub over https/ssh) as a remote
$ sc import --repo /path/to/git/repo
$ sc export --to /path/to/git/repo
$ sc clone https://github.com/org/repo.git ./mirror
# open a native .sc repository browser (read-only and keyless)
$ cd apps/desktop
$ npm ci && npm run tauri dev How it works
- A worktree is a copy-on-write overlay over an immutable base snapshot — forking N agents is O(overlay), not O(repo); base blobs are shared, never copied
- Content lives only in RAM and touches disk only on an explicit checkout — no FUSE mount, no kernel extension, which is what makes "zero residual artifacts" provable rather than aspirational. Tools that need real files (compilers, test runners) get a materialized temp checkout, auto-cleaned
- Bounded blob budget with LRU eviction; optional spill to an auto-cleaned content-addressed temp dir keeps the zero-residue guarantee
- Native committed secrets: env vars and keys committed into repo state, encrypted at rest and in transit, decrypted only in an authorized execution context
- Durable
.sc/repos: branches, merge with real conflict ergonomics (sc conflicts/sc resolve), history editing (cherry-pick, rebase, amend, undo), sparse checkouts, accidental-secret scanning, per-path encryption, packfiles/GC - Per-branch access control: a private branch seals every
object it introduces — snapshots, trees, blobs — with randomized
per-object encryption, so non-recipients see no content, no file
paths, no messages, no DAG shape. Grants are O(1) key wraps;
revocation rewraps keys without ever writing plaintext to the
object store;
sc branch publishreplays the sealed history into public space in one atomic,sc undo-able ref move, re-running the secret scanner at the boundary - Provenance built in: Ed25519-signed commits with
sc verify --requireas a history-rewrite tripwire, and sealed agent-session transcripts attached to commits — plaintext never enters the object store; a keyless clone gets ciphertext only - sc-native transports over SSH and HTTP(S) — in-binary TLS
(
sc+https://, first-connection (TOFU) pinning), token-based access control, connection caps, session timeouts, streaming packs that move multi-GiB repos in bounded RAM — plus partial clone - Git interop via
gix, isolated in one crate — import a repo's HEAD in-process, export history back to Git commits, or sync bidirectionally with a Git remote, local or hosted (GitHub over https/ssh) - A native Tauri v2 desktop app reads
.screpositories directly through the Rust crates — not through CLI output or a Git export — and browses local and remote-tracking refs, the all-parent snapshot DAG, signature and transcript provenance, public trees, and first-parent diffs - The Phase 35 desktop read model is deliberately read-only and keyless: protected files cross IPC only as locked states, private branches remain opaque at their public manifests, and the WebView has no general filesystem, shell, URL, process, or object-store command
Status
Phases 1–35 are built and tested. The arc so far: in-RAM virtual
worktrees and committed secrets (P1–2); persistent repos, merge,
secret scanning, remotes, encrypted paths, packfiles/GC, Git
export (P3–9); bidirectional Git sync, secret/permission lifecycle
with rotation, revocation tombstones and bulk re-wrap, SSH transport,
agent workspaces and durable sessions with auto-merge, history
editing (P10–21); signed commits, merge ergonomics, sparse checkouts,
streaming pack transfer, sc-native HTTP transport with token access
control, partial clone, security hardening, sealed agent-session
transcripts, and listener resource limits (P22–31); in-binary TLS
for the HTTP transport and randomized protected-path encryption
(P32–33); per-branch access control — private branches sealed to a
recipient set, with O(1) grant, plaintext-free revocation, and
atomic publish (P34); and a native Tauri v2 browser over the .sc
object model, with refs, all-parent history, provenance, public trees, and
first-parent diffs while protected and private states stay safe (P35).
Feature phases ship with runnable proofs and tests — see demo/
and apps/desktop/ in the repo. Pre-1.0 and design-partner alpha:
the cryptography has not had an independent audit,
sc+https:// trust is first-connection (TOFU) pinning,
and revoking a private-branch recipient protects what is sealed
afterwards — it cannot erase what they already fetched. The
near-term promise is parallel agent workspaces and provenance,
not production secret management.
Docs: README · Architecture · Threat model · Security · Desktop app · ADRs
Frequently asked questions
- What is src-control?
- src-control is open-source version control built for fleets of AI agents. It combines copy-on-write virtual worktrees, a persistent collaborative VCS, encrypted paths and branches, signed provenance, Git interoperability, and a native desktop repository browser.
- Does src-control write agent worktrees to disk?
- Virtual worktrees stay in memory. A tool that requires real files can receive an explicitly materialized temporary checkout, which src-control cleans up automatically.
- Does src-control replace Git?
- No. src-control supports bidirectional Git interoperability, including import, export, and synchronization with local or hosted Git remotes.
- Does src-control have a desktop application?
- Yes. Phase 35 adds a native Tauri v2 desktop browser for .sc repositories. It reads the object model directly and shows refs, snapshot history and provenance, public trees, and first-parent diffs. This first slice is deliberately read-only and keyless.
- Is src-control ready for production secret management?
- No. It is a pre-1.0 design-partner alpha. The project explicitly states that its cryptography has not yet received an independent audit.