Copy-on-write workspace clones as an alternative to Git worktrees

[qeude]

Would it make sense to support copy-on-write filesystem clones as an alternative workspace strategy to Git worktrees?

On filesystems that support reflinks / CoW clones, such as APFS on macOS, T3 Code could clone the current workspace almost instantly while initially sharing the underlying file data.

That would have a few interesting properties compared to a fresh Git worktree:

• ignored files such as .env would already be present
• dependencies such as node_modules or .build could be preserved
• generated files and local build caches could be preserved
• workspace creation could remain very fast and storage-efficient
• each agent would still get a fully isolated filesystem tree

This could be especially useful for projects with expensive setup or build steps.

For example, on iOS projects, a new worktree often behaves much more like a cold environment. A CoW workspace could potentially preserve SwiftPM state and, if DerivedData is made workspace-local, warm build artifacts as well.

Conceptually:

current workspace
│
├── CoW clone → agent A
├── CoW clone → agent B
└── CoW clone → agent C

On macOS this could use APFS cloning (clonefile / cp -c), with reflinks on supported Linux filesystems and Git worktrees remaining the portable fallback.

The main trade-off I see is Git semantics: each clone would effectively be its own repository rather than a Git-managed worktree, so branch/ref synchronization and merging changes back into the main workspace would need to be handled explicitly.

I don’t think this necessarily needs to replace worktrees, but it could be an interesting optional workspace backend, especially for large projects where recreating the non-Git state of the workspace is expensive.

Curious whether this is something that has already been considered.