0.10.0

gitd 0.10.0: workspaces as Kubernetes volumes, and gitd on macOS.

Kubernetes: a CSI driver

• A pod asks for a workspace like any volume — an ephemeral inline volume of the driver
  gitd.dev, with its repository and branch — and gets a copy-on-write checkout from the
  gitd on its node, with no credential in the pod.
• gitd-csi, the CSI node plugin, asks gitd for a workspace that carries its pool inside
  it, mounts the pool's objects read-only there, and binds the workspace onto the pod's
  volume; when the pod goes, it unmounts both and gitd removes the workspace.
• charts/gitd: the Helm chart running gitd (unprivileged, credentials from a Secret only
  it mounts), the plugin and kubelet's registrar on every node.
• On kind in CI, on every push: a pod commits in its workspace with no credential, and gitd
  publishes the commit to GitHub with the gitd-e2e App.
• PrepareRequest.pool_inside, released in 0.9.0, is what the plugin uses: a workspace that
  names its pool from inside itself, accepted only while the pool is truly mounted there.

macOS

• gitd-darwin-amd64 and gitd-darwin-arm64. With no overlay on macOS, gitd clones each
  template whole with APFS's clonefile(2). Ten workspaces of OCA/web on a GitHub macOS
  runner: 0.159 s and 0.7 MB each (by the volume's free space), against 1.75 s and 38.1 MB
  for a git clone --depth 1; all ten clean to git.

Guides

• docs/guides: Docker, Kubernetes, Claude Code and Codex (with bubblewrap), remote
  sandboxes (E2B, Modal) and macOS, each pointing at what CI runs of it.

Fixes

• A root reached through a symbolic link refused every workspace under it — every root
  under /tmp or /var on macOS. Found by the macOS job.

Upgrading

The contract did not change since 0.9.0. CI now refuses any change buf breaking finds
against the last release. Clients: pip install gitd==0.10.0,
npm install gitd-client@0.10.0.

0.9.0

gitd 0.9.0: any sandbox with a network, and many tenants on one gitd.

The endpoint: sandboxes that mount nothing

• A Firecracker microVM, a remote sandbox (E2B, Modal, Daytona, Runloop) or a CI runner
  elsewhere clones from gitd over HTTP with a token of gitd's own: one repository for
  reading, one sandbox repository for writing, an hour unless told, a day at most, never the
  git host's credential. gitd token issue, EndpointService, the MCP tool
  open_endpoint_access, both clients.
• Pushes land in the token's sandbox repository, never the pool; gitd publish --sandbox
  publishes the branch under the same prefix, rules, pull request and audit log as a
  workspace. End to end against GitHub on every push: a container on its own network clones
  and pushes, and gitd opens its pull request from the App's bot.
• Served by git's own git http-backend, over TLS when given a certificate (reread when
  renewed). Partial clones from pools with the whole history.

Tenants

• [[tenants]]: each customer of a platform its own key, roots, credentials and limits
  (workspaces, disk, fetches, sandbox repositories), and its own pools, templates,
  workspaces, tokens and audit log under <state>/tenants/<name>. Nothing is shared.
• Every call names its tenant by its key, on the socket and the network; an endpoint token
  belongs to one tenant. Tests try every reach into another tenant's and find it refused.
• Without tenants, nothing changes: the socket answers as in 0.8.

The API on the network

• The network address serves the API too, to a key only: --url, --key-file,
  --ca-file on the command line, Gitd(url=…, key=…) in Python, new Gitd({ url, key })
  in TypeScript. CI calls a gitd over TLS from all three.

Kubernetes, ahead of 0.10

• PrepareRequest.pool_inside: a workspace that names its pool from inside itself, so it
  works wherever it is mounted, accepted only while the pool is truly mounted there.

Security

0.9.0 was reviewed by an AI agent, not yet by a person; a person's review is still due.
The review found, and these were fixed before the release: a writable token could read
other sandboxes' unpublished commits through the pool's refs, and a tenant could fill the
shared disk through sandbox repositories. The threat model says what the endpoint and
tenants protect, and what they leave to the deployment.

Upgrading

The contract only grew (buf breaking against 0.8.0). Clients: pip install gitd==0.9.0,
npm install gitd-client@0.9.0. With tenants, gitd-mount needs each tenant's templates,
layers and roots, one line each.

0.8.0

gitd 0.8.0: what platforms ask for before they hand repositories to agents — GitHub
connected without a file, publishing rules and pull requests from a bot, what each agent
changed, workspaces with their dependencies ready, and OpenHands working on it with no
token in its sandbox.

GitHub, without editing a file

• Connections through the API (ConnectionService): the organisation's own GitHub App,
  created from a manifest in one click; signing in with gitd's public App by device flow; a
  platform's App; or a token. Kept under gitd's state, readable only by its user, encrypted
  with secrets_key_file when set, applied without a restart. gitd connect github,
  gitd connect github-app, gitd connections.
• Tokens per repository and purpose: an App's installation token reads, writes or
  opens pull requests on one repository, for an hour, kept in memory only.

Publishing rules and pull requests

• Publishing settings per prefix (PublishingService): protected and kept paths, at
  most N files, a branch prefix, presets as data (recommended protects the CI, CODEOWNERS
  and .gitmodules, keeps tests). Checked in the pool commit by commit before any push,
  merges counted for what they bring; POLICY_REFUSED otherwise. gitd publishing.
• Pull requests opened from the App's bot after the push: a draft and labelled as the
  settings say, the person who asked for the work asked to review, its body saying what gitd
  checked. End to end against GitHub on every push.
• Provenance: a publish says which agent, model, session and task did the work, kept in
  the audit log and written in the pull request, never in a commit.

What agents changed

• Changes, Diff, Compare (two workspaces or branches), Conflicts (pair by pair,
  git merge-tree in the pool) and Watch (events as they happen). On an overlay workspace
  the changes are read from the agent's own layer, with no git in the workspace: one file
  changed in kubernetes read in 0.012 s, against 0.130 s for git status.
• MCP: list_changes and show_diff, for an agent to review its own work.

Dependencies ready: warm layers

• gitd seal PATH NAME turns a workspace where the platform installed dependencies into a
  warm layer; gitd prepare --warm NAME stacks it between the template and the new
  workspace's own layer. Ten workspaces of socket.io in 0.17 s each with its 561 MB of
  node_modules, 1.9 MB in all plus the layer once, against 28 s and 561 MB each with
  npm ci; npm reads the same tree in both. gitd never runs the install, never carries the
  sealed workspace's .git, and refuses to seal while a sandbox still mounts it.

OpenHands

• examples/openhands: OpenHands' own agent works in a workspace gitd made, in a sandbox
  with no credential and no network, and gitd publishes its commit as a pull request from a
  GitHub App's bot. The same agent taken over by a prompt injection finds no token, cannot
  push, and its commit adding a workflow is refused before anything is pushed. Both run in
  CI on every push.

Upgrading

The contract only grew (buf breaking against 0.7.0). Clients: pip install gitd==0.8.0,
npm install gitd-client@0.8.0. Overlay workspaces on a warm layer need the gitd-mount of
this release, which takes two lower layers; an older one refuses them.

0.7.0

docs: the README's numbers are the benchmark's (0.7 · 11)

A hundred agents on kubernetes, on a GitHub runner: each workspace after the
first in 23 ms and 4.3 MB, all hundred in 14.5 s and 850 MB with one fetch,
against 980 s and 41,870 MB for a hundred shallow clones — 67x faster, 49x
less disk; all clean to git, an agent's commit kept in its workspace. The
README, DESIGN and the roadmap's launch line say so, with what the 4.3 MB is
and that gitd ran as root (34-36 ms through gitd-mount); the quick start is
the new copy-on-write example; installing gitd-mount names its capabilities
and the nosuid filesystem.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Josuesp1620 <josuesp1620@gmail.com>

0.6.0

docs: the benchmark's numbers in the README

Ten agents on kubernetes: with the whole history, ten clones take 18 minutes and 17 GB and
gitd 2 minutes and 5 GB, one fetch instead of ten; with the tip only, gitd is 3.2× faster
and the disk is mostly each copy's files, which copy-on-write workspaces will stop writing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Josuesp1620 <josuesp1620@gmail.com>

0.5.0

docs: a diagram of what gitd changes, without and with it, at the top…

0.4.1

fix: updating a workspace whose new commits move a submodule no longe…

0.4.0

feat: listing a repository's branches says the commit each points at,…

0.3.0

feat: the copies of repositories no workspace borrows from and nothin…

0.2.0

feat: a repository is read with the one credential that opens it, dec…