Debugging computerd against real FUSE

This skill captures the recipe for isolating bugs in computerd that only fire when the kernel-FUSE backend is the one wired up. Most unit tests run against SQLiteTestStorage and an in-process VFS or the userspace FUSE_MOUNT=shim polling driver, neither exercises the kernel-FUSE callback path. Several production-only bugs (write buffer never spilled to the VFS, spawn(cwd=/mount) deadlocks) have shipped to next and not been caught by the regular suites because the harness is hard to drive end-to-end from a dev box.

The workflow here bypasses workerd, wrangler, and the vitest-pool-workers harness. It boots the computerd SEA binary in a real docker container with /dev/fuse and SYS_ADMIN, and drives its capnweb endpoints from a plain Node script.

When to reach for this

• A user report of "wrote a file via FUSE, RPC reads see 0 bytes."
• A report of "exec hangs forever" or "computerd /health stops responding after the first shell call."
• Adding a new computerd op (FUSE callback, sync RPC, runner feature) and you want a smoke test that doesn't depend on Docker-in-DO or Cloudflare Containers.
• The harness vitest suite (packages/computer/src/test-harness/) hangs at ws.shell.exec against the docker container and you need to attribute the wedge to computerd vs workerd vs the network shim.
• Confirming a fix actually settles in the deployed binary: the SEA build is what wrangler ships, and reproducing locally with the same binary is the only way to be sure.

What you need