Not Git worktrees: LayerFS Is the Agent's File System

Camille Roux posted a tweet introducing the new project LayerFS. Here is a translation of his description: a file system that gives each agent a complete and modifiable Workspace, placed on top of shared history, without copying the base. Each agent commits in parallel. 157 snapshots take 100MB, 19.9× smaller than Btrfs+zstd. MIT license.

The first line of the GitHub repository states its positioning: Ephemeral Workspaces. Durable Shared History. LayerFS is the foundational layer beneath agents: each agent mounts a complete writable tree, works on the shared committed history, commits the changed parts when done, and then disappears.

LayerFS's Workspace is a FUSE mount point, not a virtual machine and not a container.

Core mechanisms:

Store: A single SQLite file stores all Branches, Commits, and content objects. There is no database service; each daemon and SDK process opens it directly.
Branch / Commit / Layer: A Branch is a writable line of Commits. Publishing a Branch to main adds a Layer. Content is stored in chunks, and identical data is stored only once.
Workspace: When mounted, it binds to the entire committed tree without copying. Write operations go into the Workspace's own overlay, which is saved on commit and deleted on unmount. History is never deleted.
Conflict: Commits that simultaneously modify the same file are rejected unless a .lww rule declares that the newer edit overwrites the older edit.

Each tool call gets a complete writable tree, and each result becomes a Commit. The file system itself becomes the agent's working memory.

LayerFS demo: agents run tool calls across multiple Branches, each call becomes a Commit, and the history tree grows accordingly

Data

LayerFS's public benchmarks, with data from 1.0.0, measured on main branch e5c7aaae05:

Item	Result
fs-bench (Cloudflare Computer's twelve-scenario file system benchmark, unmodified)	5.20s vs 8.88s, 1.71× faster, faster in 10 of 12 scenarios
dsh-dedup (157 snapshots of a real project, 4.94GB tree)	100.1MB vs 1,994.6MB, 19.9× smaller than Btrfs+zstd
pjdfstest (POSIX conformance, 8,798 assertions)	0 unexpected failures
fsstress (4 concurrent processes, remount after commit and compare)	3,755/3,755 entries consistent
fio (data I/O bandwidth)	Random read/write mix 1.49–2.23× faster; sequential write 0.31×, sequential read 0.81×, random write 0.40×

The fio results illustrate its trade-offs. LayerFS is not a general-purpose file system; it optimizes for agent workloads: lots of small files, snapshots, and parallel branches.

It's not the same as Git worktrees

A developer asked in the comments: isn't this just Git worktrees?

There are similarities to Git worktrees, but the differences are in several places:

Git worktrees solve the problem of "one repository, multiple working copies," but each worktree is still centered on .git. LayerFS's Workspace contains the entire tree, including .git, ignored files, dependencies, and build outputs. When you mount a new Workspace, the dependencies are already there, so you don't need to reinstall them. Git worktrees don't handle this.

The commit timing is also different. Git worktrees wait for you to manually run git commit. LayerFS automatically commits per tool call; every file read, write, grep, or Bash command produces a Commit. Every step the agent takes can be rolled back to this Commit.

LayerFS also allows recursive forking: any Commit, at any depth, can be forked into another Branch. A project can have multiple Branches, and a Branch can have multiple agents.

How to run it

Currently it runs through LayerFS × DSH, which is the dsh-layerfs plugin for DeepSeek Harness. It supports Linux, macOS (via DSH), and Windows (via WSL2). Agents fork Branches in DSH sessions, test in the Sandbox, merge, and publish to main. The Work and History tabs show each agent's Branch in real time.

Limitations

The official documentation is direct: the Store runs in Disposable mode and has no crash or power-loss durability. Use it to manage agent work and history, not as the only copy of data that cannot be reconstructed. Sequential I/O bandwidth is not good. POSIX has trade-offs: no FIFO, socket, device node, set-id bit, and atime/ctime are not maintained separately.

Project status

LayerFS 1.1.0 has been released under the MIT license. The JavaScript API is split into @layerfs/agent, @layerfs/backend, and @layerfs/runtime. The code is at github.com/Ephemeral-AI-Lab/layerfs.