git init/commit broken against DO-backed workspace: .git writes vanish, HEAD never appears

[DevmanMikey]

Summary

Against a Durable Object-backed Workspace (withWorkspace + createGitClient(), @cloudflare/computer@0.2.1, production workerd), the git flow is broken end to end:

1. ws.git.init({}) resolves successfully but writes nothing — /.git/ never gains HEAD, config, or refs/.
2. Direct workspace-fs writes under .git/ (mkdir + writeFile of HEAD/config) resolve successfully but vanish: subsequent reads report ENOENT. Non-git paths (including dotfiles elsewhere) persist fine.
3. ws.git.add() works (index + blobs land, status() reports staged files).
4. ws.git.commit() then fails with Cannot read properties of null (reading 'startsWith') inside isomorphic-git _commit, which reads <gitdir>/HEAD first thing.

Repro

On a fresh workspace: write a file, status() (throws not-a-repo, as expected), init({}) (resolves), add({paths}) (works), commit({message, author}) → startsWith TypeError. Probing /.git afterwards shows only [index, objects] — no HEAD, ever. Per-board repos (init({dir, defaultBranch})) and symbolic-HEAD-via-updateRef behave identically: silent success, nothing persists.

Impact

Any consumer relying on workspace git (commit/log/history) against DO storage hits this. We worked around it with fs-native snapshotting, but the documented git path (init/add/commit/log) cannot complete a single commit.

Happy to provide a minimal Worker repro or wrangler tail logs on request.

[aron-cf]

Thanks for the report! @agent-think can you create a minimal reproduction?

[aron-cf]

@agent-think can you create a minimal reproduction.

[agent-think]

Requested by @aron-cf

Verdict: could not reproduce

I deployed a minimal Worker using the exact reported @cloudflare/computer@0.2.1 (plus its @platformatic/vfs@0.4.0 peer) and exercised the flow on a fresh SQLite-backed Agent Durable Object for every request. In the current production runtime, .git writes persisted and the first commit succeeded.

Repro URL (expires after 60 mins): https://computer-git-do-repro-133.somber-beast.workers.dev

Open it, press Trigger bug, and watch the status and log. Each click uses a new DO instance, so it always starts with fresh storage.

Repro branch: https://github.com/cloudflare/computer/tree/repro/issue-133 — pull this branch to run the repro yourself.

Minimal repro

README.md
index.html
package.json                 # @cloudflare/computer 0.2.1; @platformatic/vfs 0.4.0
src/client.tsx               # one-button UI; selects a fresh DO
src/server.ts                # init/add/commit and direct-write probes
vite.config.ts
wrangler.jsonc               # SQLite DO; compatibility_date 2026-09-10

The essential backend flow is:

await ws.fs.writeFile("/hello.txt", "hello from issue 133\n");
const before = await ws.git.status({ dir: "/" });
await ws.git.init({ dir: "/", defaultBranch: "main" });
const head = await ws.fs.readFile("/.git/HEAD", "utf8");
const entries = await ws.fs.readdir("/.git");
await ws.git.add({ dir: "/", paths: ["hello.txt"] });
const commit = await ws.git.commit({
  dir: "/",
  message: "first commit",
  author: { name: "Repro", email: "repro@example.test" },
});

Observed vs expected

The root page returned HTTP 200 HTML. A POST to the same fresh-DO endpoint used by the button also returned HTTP 200 and, in abbreviated form:

{
  "statusBeforeInit": { "ok": true, "value": [{ "path": "hello.txt", "index": " ", "worktree": "?" }] },
  "init": { "ok": true, "value": "resolved" },
  "afterInit": {
    "gitEntries": { "ok": true, "value": ["HEAD", "config", "hooks", "info", "objects", "refs"] },
    "head": { "ok": true, "value": "ref: refs/heads/main\n" }
  },
  "add": { "ok": true, "value": "resolved" },
  "commit": { "ok": true, "value": { "oid": "d9a009fa700e8e1fdaab38ac2d6508fd41cb0558" } },
  "directWriteProbe": {
    "ok": true,
    "value": {
      "ordinaryDotfile": { "ok": true, "value": "persists\n" },
      "gitHead": { "ok": true, "value": "ref: refs/heads/main\n" }
    }
  }
}

Expected: init() creates HEAD, config, and refs, and commit() returns an OID. That is what I observed. I did not observe the reported missing HEAD or startsWith exception. One additional difference from the report is that pre-init status() returned the file as untracked rather than throwing not-a-repository.

Validation completed with npx tsc --noEmit, npx vite build, live root fetch, and a live trigger request.

Root-cause hypothesis

The startsWith exception would be a secondary consequence of isomorphic-git receiving a null/missing HEAD; the primary failure is the earlier disappearing write. That write path runs through packages/computer/src/git/adapter.ts (method forwarding and promise-FS exposure) into SQLiteWorkspaceProvider.writeFile, and that exact path worked in this deployment. This points more toward an environment/dependency-lock/compatibility-date discrepancy or a transient runtime issue than a currently reproducible defect in that path. The reporter's exact lockfile, compatibility_date/flags, and smallest Worker source would help isolate the difference.

🤖 generated by the repro-agent