# Loopback Harness

**Your driver as an `fs/promises`-shaped object, in-process — no kernel, no privileges, every platform.**

```ts
import { createLoopback } from "mountx";
import type { Loopback } from "mountx";
```

## `createLoopback(driver)`

```ts
function createLoopback(driver: FsDriver): Loopback;
```

A driver with every optional method present (missing ones throw `ENOSYS`), every path normalized before the driver sees it, capabilities resolved, and two whole-file conveniences on top:

```ts
interface Loopback extends Required<Omit<FsDriver, "capabilities" | "mountx">> {
  readonly driver: FsDriver;
  readonly capabilities: ResolvedCapabilities;
  readonly mountx: MountxExtensions | undefined;
  readFile(path: string): Promise<Uint8Array>;
  writeFile(path: string, data: string | Uint8Array): Promise<void>;
}
```

```ts
const fs = createLoopback(driver);

fs.capabilities; // every capability resolved
fs.driver; // the driver you passed
await fs.writeFile("/a.txt", "text"); // create + truncate
await fs.readFile("/a.txt"); // no handle dance
```

This is what driver authors test against, and what the Tier-0 conformance suite runs on. **Anything that works through `createLoopback()` works through a mount** — the loopback is not a mock, it is the same normalization and capability layer a real session applies, minus the kernel.

## Next

- [Mounting](/guide/mounting) — the same driver, as a folder.
- [Capabilities](/reference/capabilities) — what `fs.capabilities` decided, and how.