Drive9 v0.10.0

Drive9 v0.10.0

Drive9 v0.10.0 is the first public release. It gives coding agents a persistent, mountable working directory where standard developer tools keep working — Git, SQLite, build tools, artifacts, and multi-step agent runs — across sandboxes, clouds, and machines.

The core idea is simple: an agent workspace should not be a disposable sandbox volume, and it should not force agents to use an object-storage API. Drive9 exposes a filesystem-shaped workspace with server-side state, local execution layers, scoped permissions, fast Git paths, and LayerFS isolation for parallel attempts.

Core workspace capabilities

1. Git workload: standard Git commands still work

Drive9 keeps the coding-agent workflow familiar. Agents can still use normal Git commands inside a mounted workspace:

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

The important part is state ownership. Source files, patches, config changes, logs, 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, and tool caches — stays in the local layer for performance.

For large repositories, Drive9 adds a fast path:

drive9 git clone --fast --blobless --hydrate=sync https://github.com/org/repo /mnt/workspace/repo

Fast clone represents the clean tree as workspace metadata instead of pushing every clean checkout file through ordinary FUSE writes. Dirty changes still enter the workspace or layer. Local Git metadata and object caches stay local so Git remains fast.

Fast worktrees extend the same model to branch-style agent work:

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:

drive9 ctx fork auth-experiment --from owner

A fork can read the parent state but isolates later writes into a new context. 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. Drive9 now has Workspace Zone scoped tokens: path- and operation-scoped credentials that limit an agent to the exact part of the workspace 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 high-churn local paths such as .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 stay local at runtime but should not be lost between sandboxes.

Other notable improvements

• 2–3× faster cold reads — Small files are fetched in a single request, repeated reads hit revision-bound local disk cache, and concurrent fetches are deduplicated without serving stale data.
• Fuller POSIX behavior — Symlinks, hardlinks, recursive copy (drive9 fs cp -r), byte-range reads (drive9 fs cat --offset --length), chmod, preserved create modes, and stable file identity make Drive9 mounts behave more like real working directories.
• Durability controls — drive9 mount --durability=auto|interactive|fsync|close-sync|write-sync lets users choose the right latency/persistence tradeoff. FUSE crash-recovery hardening protects staged writes between fsync and async commit.
• Portable profile — a built-in profile for moving local overlay state across machines and sandboxes.
• Kotlin and Swift SDKs — native mobile/JVM SDK coverage alongside existing Python and JavaScript SDKs.
• Production hardening — Alibaba OSS/KMS/ACK support, tenant metrics, semantic-worker scheduling improvements, tiered e2e/performance gates, and broader live POSIX/Git/SQLite coverage.

Getting started

# Install
curl -fsSL https://drive9.ai/install.sh | bash

# Mount a workspace
drive9 mount :/ ~/agent-work

# Clone a repo into it using the fast Git path
drive9 git clone --fast --blobless --hydrate=sync https://github.com/your/repo ~/agent-work/repo

Full technical changelog

The complete PR-level changelog covering all four weeks of development is available at docs/release-notes/2026-05-18-to-2026-06-14.md.