Drive9 v0.10.0

1. Git workload: standard Git commands still work

Drive9 keeps the coding-agent workflow familiar. Agents use normal Git commands inside a mounted workspace — no special SDK required.

cd /mnt/workspace
git clone https://github.com/org/repo .
git checkout -b fix-auth
git status
git add . && git commit -m "fix auth"

Source files, patches, config changes, and collaborative workspace output live in the server-side Drive9 workspace. High-churn local execution state — .git metadata, Git objects, hydrate cache, dependency directories, build output — stays in the local layer for performance.

For large repositories, Drive9 adds a fast path that represents the clean tree as workspace metadata instead of pushing every file through FUSE writes:

drive9 git clone --fast --blobless --hydrate=sync https://github.com/org/repo /mnt/workspace/repo
drive9 git worktree add --fast --blobless -b fix-auth /mnt/workspace/repo /mnt/workspace/repo-fix-auth HEAD

2. LayerFS: isolated filesystems for parallel agent attempts

LayerFS is the most important workspace primitive in this release. It lets agents create isolated writable layers from the same base workspace, run different attempts in parallel, inspect the diff, checkpoint progress, roll back failed attempts, and commit successful work back to base.

# Create two isolated layers from the same base path.
drive9 fs layer create --name fix-auth --tag task=auth /repo
drive9 fs layer create --name fix-session --tag task=session /repo

# Mount each layer into a separate sandbox or local path.
drive9 mount --layer tag:task=auth :/repo /tmp/fix-auth
drive9 mount --layer tag:task=session :/repo /tmp/fix-session

Each layer has its own write space. Agent A can test a rateLimit(user) fix while Agent B tries a cache-based session fix. The base workspace remains unchanged until a layer is committed.

drive9 fs layer diff tag:task=auth
drive9 fs layer checkpoint --label before-final-test tag:task=auth
drive9 fs layer rollback tag:task=session
drive9 fs layer commit tag:task=auth

Commit is conflict-aware, not a blind overwrite. If the base changed under a layer, Drive9 reports a conflict and keeps the base safe. Failed or stale attempts do not silently replace newer work.

3. Context fork: isolate a whole workspace context

For larger experiments, Drive9 supports server-side copy-on-write context forks. A fork can read the parent state but isolates later writes into a new context.

drive9 ctx fork auth-experiment --from owner

It is heavier than a layer and is intended for full workspace branches: another agent, another direction, or a longer-running experiment that should not mutate the parent context. LayerFS is the lightweight tool for parallel attempts inside a workspace; ctx fork is the larger boundary for splitting an entire workspace context.

4. Scoped tokens: least privilege inside the workspace

Long-running agents should not automatically receive full read/write access to the whole workspace. Workspace Zone scoped tokens limit an agent to the exact paths and operations it needs.

# Issue a token that can only read/list /repo.
drive9 token issue repo-reader --ttl 1h --allow /repo:read,list

With that token, the permission boundary is inside the workspace:

cat /mnt/workspace/repo/README.md        # allowed
echo x > /mnt/workspace/repo/new.txt     # denied if token is read-only
cat /mnt/workspace/secrets/token.txt     # denied if outside scope

Owners can issue and revoke scoped tokens from the CLI/API. Access is no longer just “can this sandbox see the whole disk?”

5. Pack/unpack: warm restore for local execution state

Drive9 does not treat every local execution artifact as collaborative workspace state. The coding-agent profile keeps .git, dependency caches, build output, and tool caches in the local layer. drive9 pack and drive9 unpack make that local layer portable:

drive9 pack --local-root /tmp/drive9-local --remote-root /repo --profile coding-agent
drive9 unpack --local-root /tmp/drive9-local --remote-root /repo --profile coding-agent

This is a warm-restore mechanism for sandbox replacement. The server-side workspace remains the source of truth for collaborative files; pack/unpack restores expensive local execution state that should not be lost between sandboxes.