await sandbox.mounts.add({
  path: "/mnt/data",
  remote: "s3:my-bucket",
  backend: "s3",
  creds: { access_key_id: "...", secret_access_key: "...", region: "us-east-1" },
});

await sandbox.exec.run("ls /mnt/data");

Design

Mounts survive hibernate/wake naturally — savevm captures the live FUSE state + rclone daemon, loadvm restores both. We lean on the platform's snapshot mechanism
rather than fighting it.

An earlier revision in this branch built encryption-at-rest + a persistent: true opt-in + an OnWake replay hook to "officially" support hibernate-survival. After
live testing on dev showed savevm/loadvm already handled it correctly, all that came back out — simpler implementation, same end-user behavior. Explicit
mounts.remove(path) runs fusermount3 -u when a user wants a mount gone.

What's in the box

- Rootfs: fuse3 + rclone baked into Dockerfile.default, plus /etc/fuse.conf with user_allow_other
- Shared service internal/mounts/ — probe → write config to tmpfs (mode 0600) → exec rclone mount --daemon
- API POST/GET/DELETE /sandboxes/:id/mounts registered in both internal/api (combined mode) and internal/worker (server mode), same Service underneath
- SDKs TS + Python: mounts.add/list/remove
- CLI oc mounts add/list/rm
- Backend templates for s3, gcs, azureblob, sftp, webdav, dropbox; raw rcloneConfig escape hatch for anything else
- Docs docs/sandboxes/mounts.mdx

Test plan

- Unit tests for rclone config rendering (each backend, raw passthrough, deterministic ordering, error cases)
- Unit tests for the in-memory mount registry
- End-to-end on dev (app2.opensandbox.ai): real S3 bucket — add → read → hibernate → wake → read → remove all green
- CI integration against MinIO (deferred — local MinIO container in CI)